DTU ProjectLab - User contributions [en-gb]

Agile & Traditional PM cocktail

2018-02-27T19:35:31Z

Benedek Zajkas: /* Limitations */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model <ref name="Comparison"> </ref>]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles <ref name="Manifesto"> </ref>]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure 2 the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology <ref name="agilemethodology"> </ref>]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach <ref name="Mix"> </ref>]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

In the followings a hybrid method is developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However, it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by ''doing'' projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:30:56Z

Benedek Zajkas: /* Application of the blended approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model <ref name="Comparison"> </ref>]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles <ref name="Manifesto"> </ref>]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure 2 the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology <ref name="agilemethodology"> </ref>]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach <ref name="Mix"> </ref>]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

In the followings a hybrid method is developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:27:57Z

Benedek Zajkas: /* Application of the agile approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model <ref name="Comparison"> </ref>]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles <ref name="Manifesto"> </ref>]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure 2 the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology <ref name="agilemethodology"> </ref>]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach <ref name="Mix"> </ref>]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:24:45Z

Benedek Zajkas:

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model <ref name="Comparison"> </ref>]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles <ref name="Manifesto"> </ref>]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology <ref name="agilemethodology"> </ref>]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach <ref name="Mix"> </ref>]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:23:51Z

Benedek Zajkas:

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles <ref name="Manifesto"> </ref>]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology <ref name="agilemethodology"> </ref>]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach <ref name="Mix"> </ref>]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:23:13Z

Benedek Zajkas:

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles <ref name="Manifesto"> </ref>]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach <ref name="Mix"> </ref>]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:19:20Z

Benedek Zajkas:

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles <ref name="Manifesto"> </ref>]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:18:10Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 2: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:17:58Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: The agile principles]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 1: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:15:53Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|1450px|thumb|center|Table 1: Comparison of agile and traditional project management approach]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 1: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:14:43Z

Benedek Zajkas: /* Application of the traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 1: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:14:25Z

Benedek Zajkas: /* Application of the traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|center|900px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 1: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:13:55Z

Benedek Zajkas: /* Application of the agile approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|center|900px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 1: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:13:34Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1450px|thumb|center|Table 1: Comparison of agile and traditional project management approach]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:13:07Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1400px|thumb|center|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:12:56Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1400px|frameless|center|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:12:47Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1300px|frameless|center|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:12:38Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1200px|frameless|center|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:12:25Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|1500px|frameless|center|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:12:10Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|800px|frameless|center|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:10:23Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|center|{800}x{300}px|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:09:52Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|center|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:09:21Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg|Table 1: Agile and traditional project management comparison]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:05:57Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:05:17Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|{1800}x{350}px]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:05:07Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|frameless|{1800}x{350}px]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:04:50Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|frameless|{800}x{350}px]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:04:03Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|frameless|{100}x{350}px]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T19:03:38Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|{100}x{350}px]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T18:57:45Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|{800}x{350}px]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T13:24:27Z

Benedek Zajkas: /* Application of the traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in Figure 1.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T13:24:02Z

Benedek Zajkas: /* Application of the traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Similarly, in general bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects also usually require formal documentation throughout the life cycle.

One of the methodologies that is derived from the traditional approach is the waterfall methodology. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T13:20:55Z

Benedek Zajkas: /* Application of the traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

As it has been mentioned, the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for the traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T12:45:49Z

Benedek Zajkas: /* Abstract */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. Firstly the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T12:44:02Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T12:43:02Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg|thumb|{width}px]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T12:33:09Z

Benedek Zajkas: /* Application of the agile approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg|thumb|right|350px|Figure 2: The Scrum methodology]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

File:APprinc.jpg

2018-02-27T12:29:57Z

Benedek Zajkas:

Agile & Traditional PM cocktail

2018-02-27T12:29:22Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APprinc.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

File:Agileexam01.jpg

2018-02-27T12:27:16Z

Benedek Zajkas:

Agile & Traditional PM cocktail

2018-02-27T12:26:37Z

Benedek Zajkas: /* Application of the agile approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APAPbedi.png]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Agileexam01.jpg]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

File:Zbedi005.jpg

2018-02-27T12:24:52Z

Benedek Zajkas:

Agile & Traditional PM cocktail

2018-02-27T12:23:30Z

Benedek Zajkas: /* Comparison of the agile and traditional approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APAPbedi.png]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Zbedi001.jpg]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:Zbedi005.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-27T10:51:10Z

Benedek Zajkas: /* Application of the agile approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APAPbedi.png]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Zbedi001.jpg]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:bedikep.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

File:Bedi001.jpg

2018-02-27T10:44:54Z

Benedek Zajkas:

Post-Project Review

2018-02-26T17:37:11Z

Benedek Zajkas: /* Post-Project Review to improve organizational learning */

When finalizing a project and providing a deliverable, a project manager does not necessarily know if the project can be considered a success. Thus, a methodology to gain tacit-knowledge can be done by using Post-Project Reviews (PPR). PPR is a tool to "evaluate project results in order to improve future projects methods and practises"<ref name="orglearning"> Von Zedtwitz, M. (2002). Organizational learning through post-projects reviews in R&D. ''International Institute for Management Development'' [online]. Available at: http://onlinelibrary.wiley.com/doi/10.1111/1467-9310.00258/full </ref>. It is arguably a tool within the uncertainty perspective, as the purpose of the tool is to analyze potential failures and successes of a project. The knowledge gained can lead to minimized risk by possibly optimizing and/or preventing mistakes in subsequent projects.

Despite the usefulness of the tool, there is no fixed framework of how to conduct it. Organizations operate differently and do have a tailored methodology for execution of the review <ref name="harvest"> Schindler M. and Eppler M. (2003). Harvesting project knowledge: a review of project learning methods and success factors ''Institute for Media and Communication Management'' [online]. Available at: https://www.sciencedirect.com/science/article/pii/S0263786302000960 </ref>. Different studies depict recommendations of measures to apply before closing a project and conducting a PPR, as well as the methodology on how to conduct it. A project manager follows a set of interrelated actions in order to provide the desired deliverable, and do mainly follow the five categories known as Project Management Process Groups: Initiating, Planning, Executing, Monitoring/Controlling and Closing <ref name="PMBOK"> Project Management Institute (2013). ''A Guide to the Project Management Body of Knowledge''. 5th ed. Project Management Institute. </ref>. Simultaneously, a successful application of PPR must follow these steps. If a project manager defines the different criteria for success or failure of a project, as well as applying strict quality management during the project; An easier application of PPR can be assessed
<ref name="keyproject"> Anbari F., Carayannis E. and Voetsch R. (2008). Post-project reviews as a key project management competence ''Department of Information Systems and Technology Management'' [online]. Available at: http://production.datastore.cvt.dk/filestore?oid=539b961a4179934d1f03f6e4&targetid=539b961a4179934d1f03f6e6 </ref>. Furthermore, the review can be conducted by a combination of team-members and external facilitator. Lastly, there are two recommended debriefing methods which are ''process-based'' and ''documentation-based''. Process-based methods are debriefing methods that address the key learnings experienced during a project, and documentation-based methods"are methods on logging the knowledge obtained <ref name ="orglearning"/>.

This article focuses on the purpose fo the tool, as well presenting a methodology of applying PPR considering a new product development project. Furthermore, the article argues who are responsible for applying the tool and depict the many barriers against it.

==Big Idea==

===Post-Project Review to improve organizational learning===
[[File:doubleloopPPR.png‎|thumb|right|350px| Figure 1: Double loop learning through post-project reviews in
R&D projects <ref name="orglearning"/>]]
Post-Project Review is a formal review or a meeting of an ended project, examining the lessons that may be learned and used to the benefit of future projects <ref name="orglearning"/><ref name="busby"> Busby, J. S. (1999). An assessment of post-project reviews. Project Management Journal, 30(3), 23–29. [online]. Available at: https://www.pmi.org/learning/library/assessment-post-project-reviews-5308 </ref>. The purpose of the tool is to provide project managers with an overview of the success and failure modes from an ended project. The introduction of evaluation guidelines to an organization should lead to a more efficient way to manage projects as previous issues can be avoided, and safe solutions can be applied repeatedly. Furthermore, the experience from a project is documented in such a way that it is available for everybody to use it in future projects and not just linked to key employees who might not be present in the future<ref name="harvest"/>.

The tool can be considered within the domain of uncertainty, as one of the four perspectives on how to do projects. PPR is a tool to acknowledge [http://apppm.man.dtu.dk/index.php/Lessons_learned_-_a_tool_for_sharing_knowledge_in_project_management lessons learned] from a project, and a method that emphasizes reflections. Application of the tool gives an additional possibility to adapt to other processes and increase people's competencies and awareness to issues <ref name="DOproj"> Geraldi J, Oehmen J., Thuesen C. and Stingl V.(2017). ''How to DO projects: A Nordic flavour to managing projects''. Danish Standards Foundation.</ref>.

PPR is a tool that can be utilized in any type of project and has clear benefits regarding gain of knowledge and lessons learned. The tool is a way for an organization to increase the tacit-knowledge sharing, as the knowledge shared is based on experiences and not facts <ref name="goffin"> Goffin K. and Koners U. (2011). Tacit Knowledge, Lessons Learnt, and New Product Development. ''The Journal of Product Innovation Management''.</ref>. Considering the different types of projects conducted, the PPR is a method emphasized especially within the domain of new product development and R&D projects. Product development is a time-consuming process, and the learning curve is depended on knowledge-sharing. According to Goffin and Koners (2011), it is "necessary to pass the knowledge of lessons learned between project teams in order to improve the performance of product development"<ref name="goffin"/>.

Von Zedvitz (2002) goes even further when defining what type of learnings that are generated when conducting a PPR, by stating that "post-project review focuses on the link between team-learning and organizational learning" <ref name = "orglearning"/>. The idea is that PPR do not only provide single-loop learning but double-loop learning. Single-loop learning considers "detection and corrections of mismatches between experience and a reference system without questioning or altering the value of the system". However, double-loop learning considers the detected "mismatch and implements measures to correct the reference-system" <ref name="change"> Rasmussen L.B. (2011). ''Facilitating Change using Interactive Methods in organizations, communities and networks''. Polyteknisk Forlag. </ref>. PPR allows organizations to gain knowledge from project-specific experiences, and then make it available to a "corporate-wide pool of organizational and technical knowledge pool"(as displayed in figure 1) <ref name="orglearning"/>.

===Lack of Framework===
Despite the tool's purpose, there is no standardized framework provided on how to conduct it. The reason for that is that all organizations operate differently, and may have a strategical aim that differs from other competitors. Thus, it is not possible to give a step-by-step description of how to conduct the review. Furthermore, this means that there is no literature that clearly depicts who are responsible for conducting the review (This is further discussed in section 3.1).

There are different studies published that depict their method of conducting a PPR. A study conducted by Schindler and Eppler (2003) states that organizations lack a clear and systematic way of logging knowledge obtained from projects. Thus, they have recommended two debriefing-process methods for the post-project review, which is: '''process-based''' and '''documentation-based methods'''. Process-based methods are the methods of acquiring the lesson learned from concluded projects, whereas the idea is to gather the project-team to answer four main questions <ref name="harvest"/>

*What was supposed to happen?
*What actually happened?
*Why were there differences?
*What can you learn from this experience?

Secondly, the document-based methods aim is to learn from the project experiences gathered. Documentation-based methods focus on aspects of experiences gathered from current project with knowledge gathered throughout the history of the organization. There are mainly three ways of documenting the lessons learned <ref name="harvest"/>:

*'''Micro Articles'''
*'''Learning Histories'''
*'''RECALL'''

Micro-article is a short article that depicts topic and project description, where the main trait is that there are graphical representations of the key learnings. Furthermore, Learning Histories are dense reports that provide more context or remarks of learnings obtained. Lastly, RECALL is an individual documentation method where participants address their personal learnings. It is important to emphasize that this is one out of several studies on how to conduct a PPR. The tool contains high-flexibility considering how to use it, and is mainly depended on the type of projects and how the organization operates regarding <ref name="harvest"/>.

===Utilization of Post-Project Review===
The previous section states that there is no fixed framework on how to conduct a post-project review. The purpose of the tool is to ensure knowledge-sharing between project-teams and increase efficiency and effectiveness of execution of future projects <ref name="learnorg"> Kransdorff A. (1996). Using the benefits of hindsight - the role of post-project analysis. ''The Learning Organization''. Vol 3 Issue 1: p.11-15. [online]. Available at: https://doi.org/10.1108/09696479610106763 </ref>. Conducting a PPR requires a foundation of criteria, that are considered before and during a project. A study conducted by Anbari et. al (2008), provides a detailed overview of measures to be applied to the processes of a project. The process groups are according to the PMBOK guide defined as following <ref name="PMBOK"/>:

<ol>
<li> '''Initiation:''' Defining a new project or a new phase of an existing project, as well as obtaining authorization to initiate a phase
<li> '''Planning:''' Development of a scope statement that clarifies future decision-making in order to attain the objectives.
<li> '''Execution:''' The processes initiated in order to complete the work
<li> '''Controlling:''' The measures applied to maintain, review and regulate the progress
<li> '''Closing:''' Finalizing all activities and closing the project
</ol>

====Initiation Process====
When starting or pursuing the next phase of a project, a careful analysis of which criteria to measure against success or failure of a project should be conducted. Typically applied criteria are if project deliverable is given on-time within the budget, as well as it satisfies the different technical and legal specifications. These type of criteria are according to Project Management Institute (PMI) considered the "triple constraints", as these criteria consider scope, time and cost. Projects considering triple constraints theory may be helpful for future project managers to determine the most effective approach to address a certain issue <ref name="keyproject"/>.

====Planning Process====
During the process of establishing the scope of the project and refining the objectives; It is according to Anbari (2008) recommended to "use quality planning tools in order to ensure customer involvement with project team" <ref name="keyproject"/>. Examples of quality planning tools are Quality Function Deployment (QFD) which aids management to identify customer needs, wants expectations and translates it into a technical recommendation. Another tool is multi-criteria decision-making to [http://apppm.man.dtu.dk/index.php/Analytic_Hierarchy_Process Analytical Hierarchy Process (AHP) ]that considers subjective values to different components and technical project deliverables. Utilization of quality management tools decreases the chances scope creep, cost overruns and specification gaps. <ref name="praktisk"> Rolstsdås, A., Olsson, N., Johansen, A., & Langlo, J. A. (2014). Praktisk prosjektledelse. Bergen: Fagboklaget Vigmostad & Bjørke. </ref> <ref name="keyproject"/>.

====Executing Process====
Considering that the quality management tools are applied by the management in the two first process groups, a solid foundation for PPR is provided as it gives a clear overview over the different criteria for successes and failures. Furthermore, the quality management tools aid a proper execution of the project as it clarifies the certain expectations the project customer and/or final user has to the deliverable <ref name="keyproject"/>.

====Monitoring/Controlling Process====
Given that the use of quality management tools was insufficient and was the cause of quality deficiencies; The recommendation is to use to quality improvement approaches. Examples of improvement approaches can be the six sigma method, seven-step method, benchmarking, quality audits etc. The idea behind these methods is to identify causes for quality deficiencies and analyze which measures to apply in order to meet customer expectations <ref name="keyproject"/>.

====Closing Process====
The last process is about providing the project deliverable. Usually, a deliverable is considered a success if the triple constraints are satisfied <ref name="keyproject"/>. Considering all the measures from previous processes are applied, a project manager will have a solid foundation to define the potential wrongdoings in the project. Hence, a PPR can be initiated wherein it can be conducted by for instance the debriefing methods stated in section 1.2 (process-based and documentation-based).

==Application==
As outlined in the abstract, the application of the PPR will be analyzed from a new product development perspective. Section 1.2 emphasized that the tool is yet to be standardized, and different organizations conduct it differently. Thus, one can not depict a certain framework of how to perform a PPR.

A recommendation of what measures to apply before conducting the review is given, however, how to conduct the review after a project-end are yet to be defined. Before conducting the review itself, a project manager should apply the different measures in order to have a solid foundation of criteria for the review.

This section describes an application method for PPR in light of a product-development project.

===Framework for Post-project review in a product-development project===
A study performed by Goffin et at. (2010) suggests four focus areas to better leverage knowledge generation in an organization that strives for product development. The focus areas are following <ref name="goffin"/>:

<ol>
<li> '''Facilitation-method of PPR that stimulates and emphasizes tacit knowledge'''
<li> '''Foster individual learning'''
<li> '''Team members to act as knowledge brokers'''
<li> '''Project kick-off meetings as an opportunity to review'''
</ol>

====Facilitate PPRs to Stimulate Tacit Knowledge====
When conducting the PPR, an experienced facilitator should be hired. An experienced facilitator is able to successfully apply a stimulating environment, wherein the facilitator is able to guide the discussion and generate tacit-knowledge within the team and the organization <ref name="goffin"/>. Experienced facilitators are known for using tools that make participants creative and motivated, thus, the ability for improved knowledge-sharing <ref name="change"/>.

====Foster Individual Learning====
[[File:frameworknpd.png‎|thumb|right|500px| Figure 2: Post-project review framework in a new-product development project <ref name="goffin"/>]]

Project-managers developing new products must ensure that the team-members possess the necessary motivation to strive for more learning. Knowledge may be obtained in several ways. It can be direct project experience, mentoring, participation in communities of practice or even individual reflection <ref name="goffin"/>. R&D professionals need to be encouraged to develop their expertise. By doing so, the team will have a better base on executing the project, as well as more knowledge to share with the other teams <ref name="construction"> Carillo P., Choudhary A. and Harding J. (2011). Knowledge discovery from post-project reviews. ''Construction Management and Economics'' [online]. Available at: https://doi.org/10.1080/01446193.2011.588953 </ref>

====Designate Knowledge Brokers====
Project personnel should emphasize members to transfer specific learning between each project. This method will make project-to-project learning more tangible <ref name="construction"/>. Furthermore, applying the method will ensure prevent knowledge-gaps in future projects <ref name="goffin"/>.

====Use Project Kick-Off Meetings====
Considering the planning process, where the project scope and objectives are defined; It is recommended to have a kick-off meeting in order to ensure the correct motivation and mutual understanding of what the project has to deliver and understand the objectives <ref name="goffin"/>.

===An On-Going Process===
The four main steps to perform in a product development project can be considered a reverse post-project review framework. The mission is to ensure that key-learning are to be shared between project-teams in order to aid future projects. The framework starts with having a kick-off meeting before executing a project, wherein a PPR is conducted with an experienced facilitator after the end of a project. Further on, knowledge brokers from the PPR inform the kick-off meeting for the project. This description is further illustrated in figure 2, as it clearly displays how knowledge-brokers share lessons learned from a PPR to a kick-off meeting.

Thus, the product-development PPR framework can be considered an on-going evaluation that emphasizes tacit-knowledge. Organizations execute projects differently, however, it is common that knowledge generated in any project-execution is done by failing. Therefore, it is important to have a work environment that is not judgemental, but rather open <ref name="orglearning"/>.

==Limitations==

Despite the benefits of executing a post-project review, there are uncertainty on whom are responsible of conducting the review (as mentioned in section 1.1). As organizations operate and conduct the review differently, it is not possible to define if it is a project, program or portfolio manager that is responsible. Furthermore, studies shows that organisations shows skepticism towards the use of it. This section discusses who is responsible for conducting PPR, as well as describing the reasons of why the tool is not being used to a full extent in organisations today.

===Responsibility of Post-Project Review===
According to PMBOK guide, the responsibilities of a project manager is to ensure that the project led will generate value for the organization, and adapt to the many changes in the environment, competition and marketplace. A project is a temporary endeavour wherein the purpose is to provide a certain deliverable <ref name="PMBOK"/>. A project is ended when a deliverable is provided, however, it can also be deemed done if objectives cannot be met. In cases where failure is obtained in a project, a post-project review can provide the root-causes for it.

Studies do not depict directly who are responsible for applying the tool. Previous section states that PPR is conducted in the closeout of a project, however, there is no literature stating whether it is a project, program or portfolio manager that are responsible for it.

Referring to section 1.1; Post-project review does generate better organizational learning. Thus, one can argue that the main responsible manager of the review are the managers initiating the projects. According to MSP (Managing Successful Programmes) framework, a post-project review is an activity under the domain of program management, with the "involvement of project-team members, project manager and external personnel" <ref name="msp"> AXELOS and Cabinet Office. (2010). ''Managing Successful Programmes''. 2011 edition. The Stationary Office Ltd. </ref>. Incorporating all these members will according to MSP "capture successes and problem areas associated with the execution of the project" <ref name="msp"/>.

The program manager considers not only the project deliverable, but also what benefits are gained from all projects within the program <ref name="standardprog"> Project Management Institute. (2008). ''The Standard For Program Management''. Project Management Institute. </ref>. Program manager ensures coordination of project execution. Summarily, one can argue that the project manager is responsible for the quality of the review, and the program manager is responsible for review-execution and newly obtained knowledge is shared to the upcoming project. This view can be coherent to the framework presented in the previous section, as project managers perform the review and the program manager ensure that the knowledge gets shared.

===Review Amnesia===

Considering the theory of Von Zedvitz, a post-project review's objective is to ensure knowledge generation for future projects <ref name="orglearning"/>. However, despite the tool's purpose, utilization of PPR lacks in organizations. A study conducted by Schindler and Eppler (2003), states that conducting "a successful post-project review requires personnel that are willing to invest time, having the right motivation, as well as the individual skills and the discipline"<ref name="harvest"/>.

These abilities may be hard to require from personnel after a project-closeout. The main reasons for the lack of PPR in organizations are due to scepticism regarding the benefits of it. Project manager and team tend to have difficulties understanding the value created by performing such a review, and rather consider it costly and time-consuming <ref name="busby"/>.

Usually, there is high time pressure of finalizing the project, including tasks that await completion. According to Busby (1999), "project managers want to minimize cost allocated to their project in general, especially towards the end" <ref name="busby"/>. As addressed earlier, the project manager is hired to provide a deliverable within a certain time-frame. Thus, project manager tends to not see the value for their own project by conducting a PPR, as the benefits from the review are for the future projects and not the current one. Therefore, it is important for a program manager to ensure that project manager and team understand the benefits generated for the organization and the program by using PPR.

Program managers need to use the necessary time to ensure better sharing of projects, either by performing the documentation themselves or allocating responsibility of the documentation to employees that can see the value of knowledge-sharing. A method of increasing motivation is to graphically show the long-term benefits that are obtained by performing such a review <ref name="busby"/>. Program managers goal is to ensure that projects provide a deliverable that together will provide the program desired benefit.

According to Schindler and Eppler (2003) project managers tend to have a weakness of admitting their wrongdoings <ref name="harvest"/>. Therefore, they prefer to pursue the next project rather than analyzing potential mistakes from the previous one. For PPR to be favourably performed, the mindset of the managers must change. A suggestion would be that program and portfolio managers apply measures, showing that failure can lead to success <ref name="orglearning"/>.

Requiring the skills and discipline to conduct such a review is of high importance, however, Von Zedwitz (2002) discovered that personnel do have troubles of providing objective reflections upon past actions and their consequence <ref name="orglearning"/>. Furthermore, participants tend to repress experiences as they may be uncomfortable to share it. Maintaining social relationship do usually matter for most people, and management is afraid of a post-project review being a platform to blame, criticize and recriminate each other <ref name="keyproject"/>.

==Annotated Bibliography==

<ol>
<li> '''Von Zedtwitz, M. (2002). Organizational learning through post-projects reviews in R&D.''' - The author has several acknowledgments regarding R&D innovation and development considering organizational changes. The article depict how organizations benefits from using post-project review, as well as how to incorporate the tool. Furthermore, it adresses why R&D organizations are sceptical against conducting the tool.
<li> '''Schindler M. and Eppler M. (2003). Harvesting project knowledge: a review of project learning methods and success factors''' - The article depict the proven methodologies on harvesting knowledge obtained from ended projects. Furthermore, the article depict on the benefits given to the project manager by applying the debriefing methods. Lastly, a recommendation for implementation is provided.
<li> '''Busby, J. S. (1999). An assessment of post-project reviews. Project Management Journal''' - The article is published on the Project Management Journal and depict how project-teams obtain knowledge and how they are able to share. Busby compares the tool with the reality of why it is not being fully used, and provides suggestions on how to adapt to the challenges.
<li> '''Anbari F., Carayannis E. and Voetsch R. (2008). Post-project reviews as a key project management competence''' - The article compare knowledge management with project management. It further adresses how success from previous projects affects future project, and in what way the knowledge obtained do provide an improved future project-execution. Lastly, it depict the barriers against the tool.
</ol>

==References==
<references/>

Post-Project Review

2018-02-26T17:36:39Z

Benedek Zajkas: /* Post-Project Review to improve organizational learning */

When finalizing a project and providing a deliverable, a project manager does not necessarily know if the project can be considered a success. Thus, a methodology to gain tacit-knowledge can be done by using Post-Project Reviews (PPR). PPR is a tool to "evaluate project results in order to improve future projects methods and practises"<ref name="orglearning"> Von Zedtwitz, M. (2002). Organizational learning through post-projects reviews in R&D. ''International Institute for Management Development'' [online]. Available at: http://onlinelibrary.wiley.com/doi/10.1111/1467-9310.00258/full </ref>. It is arguably a tool within the uncertainty perspective, as the purpose of the tool is to analyze potential failures and successes of a project. The knowledge gained can lead to minimized risk by possibly optimizing and/or preventing mistakes in subsequent projects.

Despite the usefulness of the tool, there is no fixed framework of how to conduct it. Organizations operate differently and do have a tailored methodology for execution of the review <ref name="harvest"> Schindler M. and Eppler M. (2003). Harvesting project knowledge: a review of project learning methods and success factors ''Institute for Media and Communication Management'' [online]. Available at: https://www.sciencedirect.com/science/article/pii/S0263786302000960 </ref>. Different studies depict recommendations of measures to apply before closing a project and conducting a PPR, as well as the methodology on how to conduct it. A project manager follows a set of interrelated actions in order to provide the desired deliverable, and do mainly follow the five categories known as Project Management Process Groups: Initiating, Planning, Executing, Monitoring/Controlling and Closing <ref name="PMBOK"> Project Management Institute (2013). ''A Guide to the Project Management Body of Knowledge''. 5th ed. Project Management Institute. </ref>. Simultaneously, a successful application of PPR must follow these steps. If a project manager defines the different criteria for success or failure of a project, as well as applying strict quality management during the project; An easier application of PPR can be assessed
<ref name="keyproject"> Anbari F., Carayannis E. and Voetsch R. (2008). Post-project reviews as a key project management competence ''Department of Information Systems and Technology Management'' [online]. Available at: http://production.datastore.cvt.dk/filestore?oid=539b961a4179934d1f03f6e4&targetid=539b961a4179934d1f03f6e6 </ref>. Furthermore, the review can be conducted by a combination of team-members and external facilitator. Lastly, there are two recommended debriefing methods which are ''process-based'' and ''documentation-based''. Process-based methods are debriefing methods that address the key learnings experienced during a project, and documentation-based methods"are methods on logging the knowledge obtained <ref name ="orglearning"/>.

This article focuses on the purpose fo the tool, as well presenting a methodology of applying PPR considering a new product development project. Furthermore, the article argues who are responsible for applying the tool and depict the many barriers against it.

==Big Idea==

===Post-Project Review to improve organizational learning===
[[File:doubleloopPPR.png‎|thumb|right|350px| Figure 1: Double loop learning through post-project reviews in
R&D projects <ref name="orglearning"/>]]
Post-Project Review is a formal review or a meeting of an ended project, examining the lessons that may be learned and used to the benefit of future projects <ref name="orglearning"/><ref name="busby"> Busby, J. S. (1999). An assessment of post-project reviews. Project Management Journal, 30(3), 23–29. [online]. Available at: https://www.pmi.org/learning/library/assessment-post-project-reviews-5308 </ref>. The purpose of the tool is to provide project managers with an overview of the success and failure modes from an ended project. The introduction of evaluation guidelines to an organization should lead to a more efficient way to manage projects as previous issues can be avoided, and safe solutions can be applied repeatedly. Furthermore, the experience from a project is documented in such a way that it is available for everybody to use it in future projects and not just linked to key employees who might not be present in the future<ref name="harvest"/>.

The tool can be considered within the domain of uncertainty, as one of the four perspectives on how to do projects. PPR is a tool to acknowledge [http://apppm.man.dtu.dk/index.php/Lessons_learned_-_a_tool_for_sharing_knowledge_in_project_management lessons learned] from a project, and a method that emphasizes reflections. Application of the tool gives an additional possibility to adapt to other processes and increase people's competencies and awareness to issues <ref name="DOproj"> Geraldi J, Oehmen J., Thuesen C. and Stingl V.(2017). ''How to DO projects: A Nordic flavour to managing projects''. Danish Standards Foundation.</ref>.

PPR is a tool that can be utilized in any type of project and has clear benefits regarding gain of knowledge and lessons learned. The tool is a way for an organization to increase the tacit-knowledge sharing, as the knowledge shared is based on experiences and not facts <ref name="goffin"> Goffin K. and Koners U. (2011). Tacit Knowledge, Lessons Learnt, and New Product Development. ''The Journal of Product Innovation Management''.</ref>. Considering the different types of projects conducted, the PPR is a method emphasized especially within the domain of new product development and R&D projects. Product development is a time-consuming process, and the learning curve is depended on knowledge-sharing. According to Goffin and Koners (2011), it is "necessary to pass the knowledge of lessons learned between project teams in order to improve the performance of product development"<ref name="goffin"/>.

Von Zedvitz (2002) goes even further when defining what type of learnings that are generated when conducting a PPR, by stating that "post-project review focuses on the link between team-learning and organizational learning" <ref name = "orglearning"/>. The idea is that PPR do not only provide single-loop learning but double-loop learning. Single-loop learning considers "detection and corrections of mismatches between experience and a reference system without questioning or altering the value of the system". However, double-loop learning considers the detected "mismatch and implements measures to correct the reference-system" <ref name="change"> Rasmussen L.B. (2011). ''Facilitating Change using Interactive Methods in organizations, communities and networks''. Polyteknisk Forlag. </ref>. PPR allows organizations to gain knowledge from project-specific experiences, and then make it available to a "corporate-wide pool of organizational and technical knowledge pool"(as displayed in figure 1) <ref name="orglearning"/>.

[[File:APAPbedi.png‎|thumb|right|350px| Figure 1: Double loop learning through post-project reviews in
R&D projects <ref name="orglearning"/>]]

===Lack of Framework===
Despite the tool's purpose, there is no standardized framework provided on how to conduct it. The reason for that is that all organizations operate differently, and may have a strategical aim that differs from other competitors. Thus, it is not possible to give a step-by-step description of how to conduct the review. Furthermore, this means that there is no literature that clearly depicts who are responsible for conducting the review (This is further discussed in section 3.1).

There are different studies published that depict their method of conducting a PPR. A study conducted by Schindler and Eppler (2003) states that organizations lack a clear and systematic way of logging knowledge obtained from projects. Thus, they have recommended two debriefing-process methods for the post-project review, which is: '''process-based''' and '''documentation-based methods'''. Process-based methods are the methods of acquiring the lesson learned from concluded projects, whereas the idea is to gather the project-team to answer four main questions <ref name="harvest"/>

*What was supposed to happen?
*What actually happened?
*Why were there differences?
*What can you learn from this experience?

Secondly, the document-based methods aim is to learn from the project experiences gathered. Documentation-based methods focus on aspects of experiences gathered from current project with knowledge gathered throughout the history of the organization. There are mainly three ways of documenting the lessons learned <ref name="harvest"/>:

*'''Micro Articles'''
*'''Learning Histories'''
*'''RECALL'''

Micro-article is a short article that depicts topic and project description, where the main trait is that there are graphical representations of the key learnings. Furthermore, Learning Histories are dense reports that provide more context or remarks of learnings obtained. Lastly, RECALL is an individual documentation method where participants address their personal learnings. It is important to emphasize that this is one out of several studies on how to conduct a PPR. The tool contains high-flexibility considering how to use it, and is mainly depended on the type of projects and how the organization operates regarding <ref name="harvest"/>.

===Utilization of Post-Project Review===
The previous section states that there is no fixed framework on how to conduct a post-project review. The purpose of the tool is to ensure knowledge-sharing between project-teams and increase efficiency and effectiveness of execution of future projects <ref name="learnorg"> Kransdorff A. (1996). Using the benefits of hindsight - the role of post-project analysis. ''The Learning Organization''. Vol 3 Issue 1: p.11-15. [online]. Available at: https://doi.org/10.1108/09696479610106763 </ref>. Conducting a PPR requires a foundation of criteria, that are considered before and during a project. A study conducted by Anbari et. al (2008), provides a detailed overview of measures to be applied to the processes of a project. The process groups are according to the PMBOK guide defined as following <ref name="PMBOK"/>:

<ol>
<li> '''Initiation:''' Defining a new project or a new phase of an existing project, as well as obtaining authorization to initiate a phase
<li> '''Planning:''' Development of a scope statement that clarifies future decision-making in order to attain the objectives.
<li> '''Execution:''' The processes initiated in order to complete the work
<li> '''Controlling:''' The measures applied to maintain, review and regulate the progress
<li> '''Closing:''' Finalizing all activities and closing the project
</ol>

====Initiation Process====
When starting or pursuing the next phase of a project, a careful analysis of which criteria to measure against success or failure of a project should be conducted. Typically applied criteria are if project deliverable is given on-time within the budget, as well as it satisfies the different technical and legal specifications. These type of criteria are according to Project Management Institute (PMI) considered the "triple constraints", as these criteria consider scope, time and cost. Projects considering triple constraints theory may be helpful for future project managers to determine the most effective approach to address a certain issue <ref name="keyproject"/>.

====Planning Process====
During the process of establishing the scope of the project and refining the objectives; It is according to Anbari (2008) recommended to "use quality planning tools in order to ensure customer involvement with project team" <ref name="keyproject"/>. Examples of quality planning tools are Quality Function Deployment (QFD) which aids management to identify customer needs, wants expectations and translates it into a technical recommendation. Another tool is multi-criteria decision-making to [http://apppm.man.dtu.dk/index.php/Analytic_Hierarchy_Process Analytical Hierarchy Process (AHP) ]that considers subjective values to different components and technical project deliverables. Utilization of quality management tools decreases the chances scope creep, cost overruns and specification gaps. <ref name="praktisk"> Rolstsdås, A., Olsson, N., Johansen, A., & Langlo, J. A. (2014). Praktisk prosjektledelse. Bergen: Fagboklaget Vigmostad & Bjørke. </ref> <ref name="keyproject"/>.

====Executing Process====
Considering that the quality management tools are applied by the management in the two first process groups, a solid foundation for PPR is provided as it gives a clear overview over the different criteria for successes and failures. Furthermore, the quality management tools aid a proper execution of the project as it clarifies the certain expectations the project customer and/or final user has to the deliverable <ref name="keyproject"/>.

====Monitoring/Controlling Process====
Given that the use of quality management tools was insufficient and was the cause of quality deficiencies; The recommendation is to use to quality improvement approaches. Examples of improvement approaches can be the six sigma method, seven-step method, benchmarking, quality audits etc. The idea behind these methods is to identify causes for quality deficiencies and analyze which measures to apply in order to meet customer expectations <ref name="keyproject"/>.

====Closing Process====
The last process is about providing the project deliverable. Usually, a deliverable is considered a success if the triple constraints are satisfied <ref name="keyproject"/>. Considering all the measures from previous processes are applied, a project manager will have a solid foundation to define the potential wrongdoings in the project. Hence, a PPR can be initiated wherein it can be conducted by for instance the debriefing methods stated in section 1.2 (process-based and documentation-based).

==Application==
As outlined in the abstract, the application of the PPR will be analyzed from a new product development perspective. Section 1.2 emphasized that the tool is yet to be standardized, and different organizations conduct it differently. Thus, one can not depict a certain framework of how to perform a PPR.

A recommendation of what measures to apply before conducting the review is given, however, how to conduct the review after a project-end are yet to be defined. Before conducting the review itself, a project manager should apply the different measures in order to have a solid foundation of criteria for the review.

This section describes an application method for PPR in light of a product-development project.

===Framework for Post-project review in a product-development project===
A study performed by Goffin et at. (2010) suggests four focus areas to better leverage knowledge generation in an organization that strives for product development. The focus areas are following <ref name="goffin"/>:

<ol>
<li> '''Facilitation-method of PPR that stimulates and emphasizes tacit knowledge'''
<li> '''Foster individual learning'''
<li> '''Team members to act as knowledge brokers'''
<li> '''Project kick-off meetings as an opportunity to review'''
</ol>

====Facilitate PPRs to Stimulate Tacit Knowledge====
When conducting the PPR, an experienced facilitator should be hired. An experienced facilitator is able to successfully apply a stimulating environment, wherein the facilitator is able to guide the discussion and generate tacit-knowledge within the team and the organization <ref name="goffin"/>. Experienced facilitators are known for using tools that make participants creative and motivated, thus, the ability for improved knowledge-sharing <ref name="change"/>.

====Foster Individual Learning====
[[File:frameworknpd.png‎|thumb|right|500px| Figure 2: Post-project review framework in a new-product development project <ref name="goffin"/>]]

Project-managers developing new products must ensure that the team-members possess the necessary motivation to strive for more learning. Knowledge may be obtained in several ways. It can be direct project experience, mentoring, participation in communities of practice or even individual reflection <ref name="goffin"/>. R&D professionals need to be encouraged to develop their expertise. By doing so, the team will have a better base on executing the project, as well as more knowledge to share with the other teams <ref name="construction"> Carillo P., Choudhary A. and Harding J. (2011). Knowledge discovery from post-project reviews. ''Construction Management and Economics'' [online]. Available at: https://doi.org/10.1080/01446193.2011.588953 </ref>

====Designate Knowledge Brokers====
Project personnel should emphasize members to transfer specific learning between each project. This method will make project-to-project learning more tangible <ref name="construction"/>. Furthermore, applying the method will ensure prevent knowledge-gaps in future projects <ref name="goffin"/>.

====Use Project Kick-Off Meetings====
Considering the planning process, where the project scope and objectives are defined; It is recommended to have a kick-off meeting in order to ensure the correct motivation and mutual understanding of what the project has to deliver and understand the objectives <ref name="goffin"/>.

===An On-Going Process===
The four main steps to perform in a product development project can be considered a reverse post-project review framework. The mission is to ensure that key-learning are to be shared between project-teams in order to aid future projects. The framework starts with having a kick-off meeting before executing a project, wherein a PPR is conducted with an experienced facilitator after the end of a project. Further on, knowledge brokers from the PPR inform the kick-off meeting for the project. This description is further illustrated in figure 2, as it clearly displays how knowledge-brokers share lessons learned from a PPR to a kick-off meeting.

Thus, the product-development PPR framework can be considered an on-going evaluation that emphasizes tacit-knowledge. Organizations execute projects differently, however, it is common that knowledge generated in any project-execution is done by failing. Therefore, it is important to have a work environment that is not judgemental, but rather open <ref name="orglearning"/>.

==Limitations==

Despite the benefits of executing a post-project review, there are uncertainty on whom are responsible of conducting the review (as mentioned in section 1.1). As organizations operate and conduct the review differently, it is not possible to define if it is a project, program or portfolio manager that is responsible. Furthermore, studies shows that organisations shows skepticism towards the use of it. This section discusses who is responsible for conducting PPR, as well as describing the reasons of why the tool is not being used to a full extent in organisations today.

===Responsibility of Post-Project Review===
According to PMBOK guide, the responsibilities of a project manager is to ensure that the project led will generate value for the organization, and adapt to the many changes in the environment, competition and marketplace. A project is a temporary endeavour wherein the purpose is to provide a certain deliverable <ref name="PMBOK"/>. A project is ended when a deliverable is provided, however, it can also be deemed done if objectives cannot be met. In cases where failure is obtained in a project, a post-project review can provide the root-causes for it.

Studies do not depict directly who are responsible for applying the tool. Previous section states that PPR is conducted in the closeout of a project, however, there is no literature stating whether it is a project, program or portfolio manager that are responsible for it.

Referring to section 1.1; Post-project review does generate better organizational learning. Thus, one can argue that the main responsible manager of the review are the managers initiating the projects. According to MSP (Managing Successful Programmes) framework, a post-project review is an activity under the domain of program management, with the "involvement of project-team members, project manager and external personnel" <ref name="msp"> AXELOS and Cabinet Office. (2010). ''Managing Successful Programmes''. 2011 edition. The Stationary Office Ltd. </ref>. Incorporating all these members will according to MSP "capture successes and problem areas associated with the execution of the project" <ref name="msp"/>.

The program manager considers not only the project deliverable, but also what benefits are gained from all projects within the program <ref name="standardprog"> Project Management Institute. (2008). ''The Standard For Program Management''. Project Management Institute. </ref>. Program manager ensures coordination of project execution. Summarily, one can argue that the project manager is responsible for the quality of the review, and the program manager is responsible for review-execution and newly obtained knowledge is shared to the upcoming project. This view can be coherent to the framework presented in the previous section, as project managers perform the review and the program manager ensure that the knowledge gets shared.

===Review Amnesia===

Considering the theory of Von Zedvitz, a post-project review's objective is to ensure knowledge generation for future projects <ref name="orglearning"/>. However, despite the tool's purpose, utilization of PPR lacks in organizations. A study conducted by Schindler and Eppler (2003), states that conducting "a successful post-project review requires personnel that are willing to invest time, having the right motivation, as well as the individual skills and the discipline"<ref name="harvest"/>.

These abilities may be hard to require from personnel after a project-closeout. The main reasons for the lack of PPR in organizations are due to scepticism regarding the benefits of it. Project manager and team tend to have difficulties understanding the value created by performing such a review, and rather consider it costly and time-consuming <ref name="busby"/>.

Usually, there is high time pressure of finalizing the project, including tasks that await completion. According to Busby (1999), "project managers want to minimize cost allocated to their project in general, especially towards the end" <ref name="busby"/>. As addressed earlier, the project manager is hired to provide a deliverable within a certain time-frame. Thus, project manager tends to not see the value for their own project by conducting a PPR, as the benefits from the review are for the future projects and not the current one. Therefore, it is important for a program manager to ensure that project manager and team understand the benefits generated for the organization and the program by using PPR.

Program managers need to use the necessary time to ensure better sharing of projects, either by performing the documentation themselves or allocating responsibility of the documentation to employees that can see the value of knowledge-sharing. A method of increasing motivation is to graphically show the long-term benefits that are obtained by performing such a review <ref name="busby"/>. Program managers goal is to ensure that projects provide a deliverable that together will provide the program desired benefit.

According to Schindler and Eppler (2003) project managers tend to have a weakness of admitting their wrongdoings <ref name="harvest"/>. Therefore, they prefer to pursue the next project rather than analyzing potential mistakes from the previous one. For PPR to be favourably performed, the mindset of the managers must change. A suggestion would be that program and portfolio managers apply measures, showing that failure can lead to success <ref name="orglearning"/>.

Requiring the skills and discipline to conduct such a review is of high importance, however, Von Zedwitz (2002) discovered that personnel do have troubles of providing objective reflections upon past actions and their consequence <ref name="orglearning"/>. Furthermore, participants tend to repress experiences as they may be uncomfortable to share it. Maintaining social relationship do usually matter for most people, and management is afraid of a post-project review being a platform to blame, criticize and recriminate each other <ref name="keyproject"/>.

==Annotated Bibliography==

<ol>
<li> '''Von Zedtwitz, M. (2002). Organizational learning through post-projects reviews in R&D.''' - The author has several acknowledgments regarding R&D innovation and development considering organizational changes. The article depict how organizations benefits from using post-project review, as well as how to incorporate the tool. Furthermore, it adresses why R&D organizations are sceptical against conducting the tool.
<li> '''Schindler M. and Eppler M. (2003). Harvesting project knowledge: a review of project learning methods and success factors''' - The article depict the proven methodologies on harvesting knowledge obtained from ended projects. Furthermore, the article depict on the benefits given to the project manager by applying the debriefing methods. Lastly, a recommendation for implementation is provided.
<li> '''Busby, J. S. (1999). An assessment of post-project reviews. Project Management Journal''' - The article is published on the Project Management Journal and depict how project-teams obtain knowledge and how they are able to share. Busby compares the tool with the reality of why it is not being fully used, and provides suggestions on how to adapt to the challenges.
<li> '''Anbari F., Carayannis E. and Voetsch R. (2008). Post-project reviews as a key project management competence''' - The article compare knowledge management with project management. It further adresses how success from previous projects affects future project, and in what way the knowledge obtained do provide an improved future project-execution. Lastly, it depict the barriers against the tool.
</ol>

==References==
<references/>

Agile & Traditional PM cocktail

2018-02-26T17:34:49Z

Benedek Zajkas: /* The agile principles (AP) and the agile manifesto */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APAPbedi.png]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Bedi001.jpg]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:bedikep.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-26T17:33:22Z

Benedek Zajkas: /* Application of the agile approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APAPbedi.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:Bedi001.jpg]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:bedikep.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />

Agile & Traditional PM cocktail

2018-02-26T17:32:31Z

Benedek Zajkas: /* Application of the agile approach */

== Abstract ==

Nowadays organizations thereby projects and business processes become more complex making project management more difficult in many cases. Choosing the right approach and the right methodology for managing a project is crucial from the PM perspective. In many cases due to the continuous customer requests and demands it is inevitable to have a flexibility in the management of projects. It can be said that there two opposite sides of project management approach exist – the agile and traditional project management approach. Having their own use cases both approaches have their advantages and disadvantages. A transition from traditional to agile project management can often be observed. This article aims to introduce a merged hybrid version of these two approaches with particular suggestions for practitioners critically reflecting on limitations. First the terms project management methodology and project management approach will be discussed. Thereafter the main traits of the traditional and agile project management approaches will be briefly elaborated on with a highlight on the main advantages and disadvantages of both approaches. Eventually a mixture of the two methodologies will be introduced with a reflection to the limitations of the model.

== Introduction==

The project management methodologies are often tailored to specific needs of the company that runs the project. Therefore there is no silver bullet for choosing the right methodology and the right approach, however there is clearly a need among companies to implement methodologies from both agile and traditional approaches <ref name="Article"> Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’</ref>. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” <ref name="Cocktail"> Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’</ref>. Addressing this problem this article elaborating on the essentials and differences of the agile and traditional approaches strives to find a solution to develop a methodology that utilizes the agile and traditional principles and guidelines as well. As agile methodologies are mostly used in software development projects, the focus of this article is narrowed down to those types of projects.

== Project management approach and methodology ==

The terms methodology and approach are usually used for the same phenomenon, however they do not mean exactly the same. As the project Management Institute defines, “methodology is a system of practices, techniques, procedures and rules used by those who work in a discipline” <ref name="Webpage"> [https://www.pmi.org/learning/featured-topics/methodology/ PMI website].</ref>. According to other literature in the field, project management methodology can be considered as “structured set of techniques and tools used for solving specific problems” <ref name="Mix"> Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’</ref>. Therefore project management methodology is commonly considered to include detailed techniques and tools.

The term project management approach is most frequently used as a set of principles and guidelines that define how a specific project is managed. Therefore project management methodologies can be considered as the application of approaches and principles. In this sense the approach is a broader term than methodology that represents methods, operative set of rules, processes and templates to be used during the project lifecycle. As an example the agile project management approach is built on the agile principles that are framed in the agile manifesto <ref name="Manifesto"> [http://agilemanifesto.org/ Agile Manifesto website].</ref>. One of the agile methodologies is Scrum that builds on the principles of the agile approach.

It can be stated that there is no single “best” methodology that would represent optimal solution for all projects in a specific environment, and some kind of adaptation is needed to be made in order to have a methodology that fits the best for a specific project.

== Traditional project management approach ==

The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way <ref name=PMBoK>[http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/reporty/pmbok.pdf Project Management Body of Knowledge (PMBoK)].</ref>. Such a uniform implementation should ensure robustness and applicability to a wide range of projects, from the simple and small projects to the complex and large ones. The traditional approach assumes that projects are predictable with a linear life cycle and their boundaries can be clearly defined making the detailed planning easy that can be followed without major changes throughout the life cycle of the project <ref name="PMBoK"> </ref>.

This robustness however results in one of the biggest disadvantages of the traditional approach. The traditional project management approach is based on mostly linear and hierarchical task relations, while projects become progressively complex, with higher number of complex interrelations and tasks. Hence the traditional approach often cannot properly reflect all complexity and dynamics of many of today’s projects <ref name="Article"> </ref>.

In software development, in many cases changes in the initial plan are inevitable due to adjustments to unpredictable and dynamic changes (for example continuous customer requests) inside or outside the project environment. It is usually also very hard to create complete project plan at the very beginning of the project due to inability to clearly define project goals, or not having all the product requirements. Therefore it can be stated that predictability is the basis of the traditional approach and the emphasis of the project management approach is on thorough planning.

=== Application of the traditional approach ===

Therefore the traditional approach is more appropriate for projects with clear initial user requirements and with clear project goals with circumstances that create low level of uncertainty. Generally, bigger projects are more appropriate for traditional approach. These projects can be typically projects with operative routines, construction and other kinds of engineering projects. These projects usually require formal documentation throughout the life cycle.

The waterfall model is one of the methodologies that is derived from the traditional approach. As it is a sequential, linear model, it has a relatively simple application. Each phase is accomplished in a defined set of time that makes the planning and controlling easier. The distinct phases are Requirement analysis, System design, Implementation, Testing (verification) and Maintenance <ref name="Comparison"> Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’</ref>. The sequential process can be seen in the following figure.

[[File:Waterfall1.jpg|thumb|right|350px|Figure 1: The waterfall model]]

== Agile project management approach ==

The new project management approaches are tightly connected with the field of the software development and software engineering. These projects are usually characterized by their reaction to continuous customer requests and adaptability to changes. This agility - as an ability to create and to respond to changes in order to create value in a turbulent environment - can be reached by an iterative approach. With the agile approach the project scope can be changed significantly during each iteration. The iterations and the frequent changes require highly empowered project team members who are involved in decision making processes. The agile approach promotes collaboration and communication between the team members, therefore it is crucial to operate with collocated teams <ref name="Manifesto"> </ref>.

=== The agile principles (AP) and the agile manifesto ===

The agile principles (AP) are stated by the Agile Manifesto that was created in 2001 by practitioners from different software development areas. These methods and principles are believed to improve team productivity and to encourage experimentation and evolution by focusing on short-term results and customer satisfaction <ref name="Manifesto"> </ref>.
The agile principles (AP) can be seen in the following table.

[[File:APAPbedi.jpg]]

=== Application of the agile approach ===

The agile approach and agile principles work very well within a single organization with smaller, standalone projects and can be used best for innovative, creative projects such as research projects, new product development projects and process improvement projects. These projects are characterized by a clear business need and vision, but on the other hand unclear project goals, high level of uncertainty, incomplete and unpredictable requests that can significantly change during the life cycle of the projects <ref name="agilemethodology"> [http://agilemethodology.org/ Agile Methodology website].</ref>. In case of the agile approach the emphasis is on execution and the project knowledge is mainly tacit without an accent on extensive documentation.

One of the most common agile methodology is Scrum, which has an emphasis on software development. As it can be seen from figure xx the project lifecycle is divided into iteration cycles that are called sprints. All iterations contain a Planning, Design, Build, Test and Review phase <ref name="agilemethodology"> </ref>. These phases are similar to those seen in the waterfall model.

[[File:bedi001.jpg]]

== Comparison of the agile and traditional approach ==

In the following table, the comparison of the agile and traditional project management approaches can be seen.

[[File:bedikep.jpg]]

== A novel project management methodology: “the traditional and agile cocktail” ==

Both traditional and agile approaches have their advantages and disadvantages, thus it is often necessary to use elements of both approaches. For the first look, the need for different approaches can be tackled on a project portfolio level inside organizations as projects can differ from each other in the same organizational environment. However due to the complexity and uncertainty of projects it can be very useful to use different techniques and methods from both approaches in regard to project characteristics.

One of the success criterias of the successful methodology usage is coherence with other company processes, which is the reason why many organizations developed their own project management methodology <ref name="Mix"> </ref>. Therefore the methodology should be aligned with the organizational goals and processes. In many cases one methodology is not enough and there should exist several other methodologies that can be used in the particular context. A good method can be finding optimal methodology elements for the project, however it is very important to understand the limitations of the utilized methodology elements.

In the followings, based on Jean Binder et al. <ref name="Cocktail"> </ref> a blended methodology will be discussed as an example of combining the traditional and agile approaches. Comparing the ISO 21500 standard and the agile principles (AP) proposed by the Agile Manifesto, recommendations are made in order to develop a blended approach.
The ISO standard is structured around 39 identified processes that are specific to project management and determine how the activities of the project are managed. These processes are grouped into ten subject groups and from a management perspective, into five process groups <ref name="ISO"> International standard ISO 21500:2012(E)</ref>.

=== Application of the blended approach ===

A hybrid method was developed by establishing correlation between the processes and the APs (Agile Principles). The resulting hybrid approach aims to combine the strengths of both approaches.

==== Integration subject group ====

There are clear correlations between most processes in this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution). These APs can enhance the capacity for dealing with ambiguity when developing the project charter and project plans, and when directing project work and controlling changes. Furthermore, almost all AP affect the way a project manager directs project work.

The project charter is recommended to obtain approval for a phased and iterative approach. However it shall be approved in the beginning of the project life cycle for all phases of the project, eliminating the need for approval at the start of every project phase (AP10 simplicity). The project plan similarly can be defined in the beginning of the project life cycle, however it must be reviewed and approved at each iteration to ensure that the key elements impacting the time, cost, quality are still realistic and relevant.

Directing and controlling the project work overlap each other and can be merged, considering that AP5 (motivated individuals) is the most applied principle for these processes. Teams that have high levels of trust and motivation don’t require strict activity control, only high level monitoring.

The controlling changes process is already aligned with AP2 (harnessing changes) recommending that the project manager should record and evaluate changes before implementing them.

Closing project phase or the project itself, and collecting lessons learned are affected by AP9 (continuous attention), AP10 (simplicity) and AP12 (team effectiveness). In these cases the processes shall be effective and efficient and only slight modifications are required in terms of aiming to make these processes the simplest (less cost, less time) possible.

==== Stakeholder subject group ====

There is a correlation between AP4 (daily stakeholder cooperation), AP5 (motivated individuals), AP6 (face-to-face communication), AP11 (self-organized teams) and the stakeholder subject group. In terms of internal stakeholders such as project team, preference should be given to people who are highly motivated individuals and can work full-time with other motivated members in the same location.

The stakeholder management should focus on the overall goal of the project that has to be affected by AP7 (working software) and AP10 (simplicity). Therefore stakeholder expectations should be focused on clear measures of progress (such as delivery of working products), and in regard to stakeholder management they should strive for simplicity.

==== Scope subject group ====

The scope subject group is mainly affected by AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) and AP10 (simplicity). Other APs that may influence the processes within this subject group are AP7 (working software), AP8 (sustainable development) and AP9 (continuous attention).
The scope shall be defined in the beginning of the project life cycle only on a high level. It must take into consideration the key features of the product using good design and simplicity. For each iterations a detailed scope can be defined.
When creating a WBS iterations shall be incorporated into the tool that can be used for high level demarcations among the necessary activities and phases. Similarly, the activities can be planned at a high level initially and then at a more detailed level at the start of each iteration. The control of the scope should be simple and flexible to allow changes in the requirements.

==== Resource subject group ====

The resources are examined with an emphasis on the perspective of human resources. In this subject group therefore AP4, AP5, AP6, AP8, and AP11 show the most correlation with the processes within resources referring to team availability, trust, pace of work, collocation, motivation and ability to self-organize. The implementing and controlling process groups inside this subject group can also be influenced by AP9 and AP12.

When establishing the project team (selecting and hiring new members) a high preference should be given to members who are available to work full time on the project, self-motivated and can work in the same location. Generally, resources can be initially estimated based on the high-level scope. In agile projects the pace of work and the amount of resources can help to determine the amount of work that can be performed in the next iteration. Hence for each iteration detailed estimates can be prepared.

When defining the project organization, sub-teams can be formed in case of a virtual and remote organization. Particularly, the development of the project team is crucial when using a blended project management methodology. A regular assessment of team skills should be conducted based on iterations in order to improve team effectiveness and behavior. Thereafter team development may be needed to compensate the lack of technical excellence and sufficient design skills.

In terms of resource control, it is necessary to be conducted on a regular basis to ensure that resources remain available in other phases of the project as it was defined by the plan. Teams effectively applying AP5 do not require detailed team member control. Behavioral competencies highlighted by the APs (such as motivation and trust) are briefly mentioned in the ISO standard but could be more explicit and constantly monitored.

====Time subject group ====

The connection between this subject group and AP1 (continuous delivery), AP2 (harnessing changes) and AP3 (iterative execution) can be defined. The sequencing of activities occurs at a high-level initially, prioritizing the activities to select those that will take place in the first iteration. The establishment of dependencies between different activities is a key factor for grouping them into iterations, and to determine their priorities.

As the process of estimating activity durations mentions periodic re-estimates (ISO 21500), it doesn’t require any adaptions. Milestones and key features (based on user and customer needs) must be taken into consideration in a high-level schedule. A detailed schedule must be prepared for each iteration with an assessment of potential changes to the high-level plan. Therefore the control of the schedule shall take place at each iteration with a thorough comparison of the high-level schedule.

==== Cost subject group ====

AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution) refer to early and continuous delivery that may affect the project budget and cash flow, and changing requirements that may affect the project costs. AP7 (working software) and AP8 (sustainable development) refer to the measure of progress and the pace of work, both possibly affecting the cash flow and payments.
The cost estimation shall be conducted on a high-level initially, with detailed overview only for those activities that are performed in the first iteration. For cash flow estimates it is crucial to consider the amount and duration of the iterations and the expected amount of work to be undertaken.
The cost control should take place during each iteration, through a comparison of the high-level budget.
Using the simplicity principle (AP10), costs shall be kept within budget by eliminating activities initially considered important and subsequently deemed not essential.

==== Risk subject group ====

This subject group doesn’t require adaption from the APs since the pro-active management of risks is recommended and mentioned in the ISO as an important success factor of projects.

==== Quality subject group ====

There is a correlation between all processes inside this subject group and AP7 (working software), AP9 (continuous attention), and AP12 (team effectiveness), defining the working products and the primary measure of progress, highlighting the need for technical excellence and good design, and suggesting regular reflections on effectiveness. However, there appears to be no need for modification of the processes, which are already in line with the APs.

==== Procurement subject group ====

In case of procurement the agile focus is on the human resources. When establishing a preferred list of human resource suppliers, preference may be given to companies having motivated people that are available (at least temporarily) to work in the same location and available to work full-time with other team members.

==== Communication subject group ====

The communication subject group and AP1 (continuous delivery), AP2 (harnessing changes), AP3 (iterative execution), AP4 (daily stakeholder cooperation), AP6 (face-to-face communication) and AP7 (working software) have a close correlation in planning and managing communication as well as in distributing information. AP10 (simplicity) is crucial to be applied when planning the communication by avoiding unnecessary information overload. Furthermore the project manager may need to conduct regular reflections on communications’ effectiveness (AP12) ensuring that a constant pace of communication is being maintained (AP8).

== Limitations ==

The above proposed project management cocktail can serve as a high-level, initial guideline for projects combining elements from the agile and traditional approach. However it is very important to note that this framework is a mixture of theories, on a theoretical level. It is usually emphasized in the literature that learning project management can be best by doing projects <ref name="Doing"> Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’</ref>.. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project.

The proposed blended approach puts a great focus on people, their motivation and the way they work in small organizations with small teams. Large, complex organizations are not considered in this methodology and it certainly gives limitations to the blended approach. Furthermore it doesn’t reflect on those situations in which individuals live in different countries forming virtual teams, or because of organizational reasons other projects demand their part time work making them unable to work full-time.
Moreover the implementation of the blended approach can be difficult considering the organizational environment and culture as key factors. The organization can be unwilling to implement new approaches changing their best practices because of the intrinsic level of uncertainty and ambiguity relating to iterative processes (for example transition from traditional towards agile). Similarly team members and stakeholders might not be aligned with the chosen approach because of their personal biases, different backgrounds.

In most cases it is easier to choose an existing methodology than create a novel, own model. Existing methodologies have already been applied on different projects so the advantages of these previous experiences can be utilized. The goal of the project management methodology is to increase efficiency and effectiveness in order to promote project success. An inappropriate methodology can have negative impact on project success or at least make managing project harder. Hence it is very crucial to consider the specific project characteristics when choosing methodologies.

== Annotated bibliography ==

'''Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’''' In this article the possibility of creating a blended project management approach from the traditional and agile approaches were examined. Covering thorough literature review the paper provides an overview of different project management approaches and methodologies.

'''International standard ISO 21500:2012(E)''' “The ISO 21500 international standard provides guidance on concepts and processes of project management that are important for, and have impact on, the performance of projects” <ref name="ISO"> </ref>. The standard is structured around 39 identified processes that are specific to PM and determine how the activities selected for the project are managed.

'''Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’''' In this article a novel methodology is proposed as a combination of the traditional and agile approaches. Using the ISO 21500 framework of processes, subject groups and process groups the authors strived to embed the 12 agile principle into the 39 ISO processes.

== References ==

<references />