Agile & Traditional PM cocktail
(→Cost subject group) |
|||
| (80 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
| + | ''Developed by 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. | + | 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== | == 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 | + | 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 == | == 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” [ | + | 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 [ | + | 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. | 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. | ||
| Line 17: | Line 20: | ||
== Traditional project management approach == | == Traditional project management approach == | ||
| − | The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way [ | + | 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 | + | 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. | 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. | ||
| Line 25: | Line 28: | ||
=== Application of the traditional approach === | === 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. | |
| − | Figure: | + | [[File:Waterfall1.jpg|thumb|center|600px|Figure 1: The waterfall model <ref name="Comparison"> </ref>]] |
| − | == Agile project management approach== | + | == 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 | + | 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) 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 | + | 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. | 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 === | === 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 [ | + | 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 == | == Comparison of the agile and traditional approach == | ||
| Line 50: | Line 58: | ||
In the following table, the comparison of the agile and traditional project management approaches can be seen. | In the following table, the comparison of the agile and traditional project management approaches can be seen. | ||
| − | Table | + | [[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” == | == A novel project management methodology: “the traditional and agile cocktail” == | ||
| Line 56: | Line 64: | ||
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. | 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 | + | 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. | + | 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 | + | 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 === | === 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 ==== | ==== Integration subject group ==== | ||
| Line 82: | Line 90: | ||
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. | 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 ==== | ==== Scope subject group ==== | ||
| Line 100: | Line 106: | ||
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. | 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 ==== | ====Time subject group ==== | ||
| Line 107: | Line 112: | ||
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. | 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 ==== | ==== Cost subject group ==== | ||
| Line 134: | Line 138: | ||
== Limitations == | == 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. Therefore particular project characteristics and real life circumstances define what methodology can be best used for managing a specific project. | + | 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. | 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. | 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. | + | 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 == | == 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 == | ||
<references /> | <references /> | ||
Latest revision as of 18:35, 16 November 2018
Developed by Benedek Zajkas
[edit] 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.
[edit] 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 [1]. The agile principles are not reflected in the ISO 21500 standard because agile and waterfall approaches were formerly considered as “competing bipolar choices” [2]. 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.
[edit] 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” [3]. 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” [4]. 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 [5]. 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.
[edit] Traditional project management approach
The traditional principles imply that methods and procedures should be applied to most of the projects in a uniform way [6]. 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 [6].
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 [1].
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.
[edit] 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 [7]. The sequential process can be seen in Figure 1.
[edit] 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 [5].
[edit] 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 [5]. The agile principles (AP) can be seen in the following table.
[edit] 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 [8]. 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 [8]. These phases are similar to those seen in the waterfall model.
[edit] Comparison of the agile and traditional approach
In the following table, the comparison of the agile and traditional project management approaches can be seen.
[edit] 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 [4]. 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. [2] 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 [9].
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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.
[edit] 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).
[edit] 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 [10]. 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.
[edit] 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” [9]. 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.
[edit] References
- ↑ 1.0 1.1 Kim Dikert, Maria Paasivaara, Casper Lassenius (2015) ‘Challenges and success factors for large-scale agile transformations: A systematic literature review’
- ↑ 2.0 2.1 Jean Binder, Leon IV Aillaud, Lionel Schilli (2014) ‘The project management cocktail model: An approach for balancing agile and ISO 21500’
- ↑ PMI website.
- ↑ 4.0 4.1 4.2 Mario Spundak (2014) ‘Mixed agile/traditional project management methodology – reality or illusion?’
- ↑ 5.0 5.1 5.2 5.3 Agile Manifesto website.
- ↑ 6.0 6.1 Project Management Body of Knowledge (PMBoK).
- ↑ 7.0 7.1 Ms.Akshita Dubey, Ms.Amisha Jain, Ms.Aditi Mantri (2015) ‘COMPARATIVE STUDY: WATERFALL V/S AGILE MODEL’
- ↑ 8.0 8.1 8.2 Agile Methodology website.
- ↑ 9.0 9.1 International standard ISO 21500:2012(E)
- ↑ Joana Geraldi, Christian Thuesen, Josef Oehmen, & Verena Stingl (2017) ‘How to DO projects’
