Waterfall vs. Pull Processes

From apppm
(Difference between revisions)
Jump to: navigation, search
(→‎Pros)
 
(94 intermediate revisions by one user not shown)
Line 1: Line 1:
−
There are many different methodologies of project management, all of them are defined by different principles and processes. A traditional, sequential methodology, is the Waterfall model. Within this model, the tasks of the project plan are sequenced and conducted in a linear way, one task must be completed before the next one begins - the process is smooth and continuous, like a waterfall. Therefore, this model is one of the simplest methods. However, the pull process-based methodologies are used to create the whole project plan more efficient and effective, it was created to eliminate confounding factors within the project, but it is more complex due to the consideration of many influences. This article provides an introduction to both methodologies, a comparison with pros and cons and a guidance how to select the right methodology for the practical usage.
+
''Developed by Johannes Eckert''
 +
 
 +
 
 +
There are many different methodologies of project management, all of them are defined by different principles and processes.<ref name="standard">Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition. Newtown Square, Pennsylvania: Project Management Institute, Inc </ref> A traditional, sequential methodology, is the waterfall model. Within this model, the tasks of the project plan are sequenced and conducted in a linear way, one task must be completed before the next one begins - the process is smooth and continuous, like a waterfall.<ref name="wrike">Project Management Methodologies, https://www.wrike.com/project-management-guide/methodologies/ </ref> Therefore, this model is one of the simplest methods.<ref name="wrike"/> However, the pull process-based methodologies are used to create the whole project plan more efficient and effective, it was created to eliminate confounding factors within the project and to avoid aimless work. Hence, the pull processes are used in the management style of Lean Project Management, typical pull processes can be find in the Scrum and Kanban methodologies.<ref name="wrike"/> This article provides an introduction to the waterfall methodology, to understand the processes within a project plan in a better way. However, the article provides a comparison of the waterfall process (push process) and the pull process. Therefore, no other methodologies e.g. Scrum and Kanban are explained. After the introduction into both processes, pros and cons are described and the relevance for the practical usage demonstrated. At the end of the article and the comparison section, a short guidance about the right selection of the processes is provided.  
 +
 
  
 
=Importance for Project Management=
 
=Importance for Project Management=
−
[[File:Impact_of_Variable_Based_on_Project_Time.png|thumb|Impact of Variable Based on Project Time]]
 
−
Project Manager's world is about focusing on the product, focusing on the team, keeping the customer happy. Project managers face here a serious challenge. In addition, they have to deal with a matrix organization, with people that they don't have power on.
 
  
−
Project management processes and the lean six sigma tools kit would certainly help project managers become more efficient by focusing on value added activities and limiting processes variation. In real life, project managers overlooked the following:
+
A project is divided in several phases (except the single-phase project), and '''five project groups'''<ref name="standard"/>.  
  
−
Establish real Customer Value:
+
[[File:Sequential relationship.png|frame|Sequential relationship<ref name="standard"/> ]]
−
S'''Bold text'''et up a scope baseline control to avoid our baseline to creep.
+
−
Build a communication plan to streamline the information flow
+
−
Assess stakeholder needs and get internal stakeholder commitment
+
−
Define Project Value Stream
+
−
When those previous factors get overlooked then project wastes start building. What happen if we are not collocated with our customer? Then it could be really difficult to establish real customer value. If we allow our customer to redirect our project team member then we would end up with scope creep.
+
  
−
Normally, our project management plan should describe the project value stream. The Work Breakdown Structure would decompose end deliverables into value-added work package and value-enabling work package. The precedence diagram network would make the value flow. First it is recommended to have an unconstraint approach. The project manager would then negotiate with the customer to which extent planned milestones could be pulled but customer target milestones. If we accept up front customer's constraints without any proper practical and logical planning effort, we would then certainly start building wastes and increase cost.
 
  
−
We have a good project management plan so why are we in trouble? We have to re-plan the project and finally we face schedule and budget overruns. Let's discover now how Lean principles can be applied to project management processes.
+
1. Initiating Process Group: Those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase.
  
 +
2. Planning Process Group: Those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve.
  
 +
3. Executing Process Group: Those processes performed to complete the work defined in the project management plan to satisfy the project specifications.
  
 +
4. Monitoring and Controlling Process Group: Those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.
  
−
'''Initiating Process Group.''' Those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase.
+
5. Closing Process Group: Those processes performed to finalize all activities across all Process Groups to formally close the project or phase.
  
−
'''Planning Process Group.''' Those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve.
 
  
−
'''Executing Process Group.''' Those processes performed to complete the work defined in the project management plan to satisfy the project specifications.
 
  
−
'''Monitoring and Controlling Process Group.''' Those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.
+
The project manager has to combine those groups and phases into a flow and take into account the product or service, his team and the customer.<ref name="attrup">Attrup et al (2015). Power in Projects, Programs and Portfolios: Achieve project excellence and create change with strategic impact 1st Edition, Djoef Publishing Inc </ref> To establish a real customer value the project should set up a scope baseline control, build a communication plan to improve the information flow, asses stakeholder needs and get the commitment of the internal stakeholder.<ref name="standard"/> As a result, there are many factors which have to be intertwine to each other. Thus, project managers are inclined to overlook something at the beginning of the project and this is when project wastes start building. It is important to align with the customers to establish the customer value, but if the customer deflects the project team members it will be end in scope creep. As an interim conclusion, the project planning has to consider a lot of things simultaneously, but it is also very important to ponder in which way and rate the steps are executed.<ref name="attrup"/>
 +
[[File:Impact_of_Variable_Based_on_Project_Time.png|frame|Impact of Variable Based on Project Time<ref name="standard"/>]]
  
−
'''Closing Process Group.''' Those processes performed to finalize all activities across all Process Groups to formally close the project or phase.
+
A project life cycle displays typically '''four characteristics''':<ref name="standard"/>
 +
 
 +
 
 +
 
 +
1. The costs and staffing level starts at the beginning of the project low, increase when the work is carried out and decrease quickly when the project is going to close.
 +
 
 +
2. Not all projects describe a typical cost and staffing curve, they may require resources early in its life cycle and therefore higher expenditures.
 +
 
 +
3. A project starts with a high amount of risk and uncertainty and run low during the ongoing life cycle.
 +
 
 +
4. The influence to the final product/service starts on an high level with low costs. At the beginning of the cycle the vision can be adjust rapidly and economically, changes at the end of the project will cause high expenses.
 +
 
 +
 
 +
 
 +
With this description of the characteristics of a project life cycle, we can have a look to the different life cycles, which are designed for different purposes.<ref name="attrup"/> The main difference of the waterfall model and the pull processes is the influence of the stakeholder and the degree of flexibility.
 +
Adaptive life cycles keep stakeholders in the loop and let them influence the project in a higher degree than a predictive life cycle (waterfall). Since, the project plan within an adaptive life cycle is more flexible, the costs of changes are lower.<ref name="standard"/>
 +
 
 +
The importance to think about the way how to execute the project and how flexible and influenceable it should be is enormous. Therefore, the following chapters will provide some clarity about the choose of the right type of process.
  
 
=Waterfall Process=
 
=Waterfall Process=
−
Process: Sequential relationship. In a sequential relationship, a phase starts only when the previous phase is complete. The step-by-step nature of this approach reduces uncertainty, but may eliminate options for reducing the overall schedule.
 
−
[[File:Sequential relationship.png|thumb|Sequential relationship]]
 
  
−
The waterfall sequential model...
+
The waterfall model (also known as predictive life cycle or fully plan-driven)<ref name="standard"/> is made of a waterfall process, which is defined by sequential relationships. A phase, consisting generally all five process groups, starts only when the previous phase is complete. This approach reduces uncertainty within the project life cycle, but it requests a high amount of tasks. As a result, this process is defined by a huge workload. In addition, the project scope, and the time and the cost required to deliver that scope, are determined at the beginning of the project life cycle. Therefore, the project is inflexible and changes are related to high costs.<ref name="standard"/>
−
Predictive life cycles (also known as fully plan-driven) are ones in which the project scope, and the time and cost required to deliver that scope, are determined as early in the project life cycle as practically possible. As shown in Figure 2-13, these projects proceed through a series of sequential or overlapping phases, with each phase generally focusing on a subset of project activities and project management processes. The work performed in each phase is usually different in nature to that in the preceding and subsequent phases, therefore, the makeup and skills required of the project team may vary from phase to phase.
+
 
−
When the project is initiated, the project team will focus on defining the overall scope for the product and project, develop a plan to deliver the product (and any associated deliverables), and then proceed through phases to execute the plan within that scope. Changes to the project scope are carefully managed and require re planning and formal acceptance of the new scope.
+
[[File:The waterfall process.jpg|frame|The waterfall sequential model<ref name="own">Own image, according to: Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition. Newtown Square, Pennsylvania: Project Management Institute, Inc </ref>]]
−
Predictive life cycles are generally preferred when the product to be delivered is well understood, there is a substantial base of industry practice, or where a product is required to be delivered in full to have value to stakeholder groups.
+
 
−
Even projects with predictive life cycles may use the concept of rolling wave planning, where a more general, high-level plan is available and more detailed planning is executed for appropriate time windows, as new work activities are approaching and resources are to be assigned.
+
The waterfall model is preferred when the product or service to be delivered is well understood.  
−
[[File:The waterfall process.jpg|thumb|The waterfall sequential model]]
+
The following phases describe the waterfall model:
 +
 
  
 
'''Requirements'''
 
'''Requirements'''
 +
 +
Firstly, the project team need an understanding of the project's function, purpose etc, the specifications of the input and output of the final product or service are studied and marked.
  
 
'''Feasibility'''
 
'''Feasibility'''
 +
 +
In the feasibility phase, the target is about finding out all the potential problems. The problems should be evaluated and analyzed and considered for the  decision making process. 
  
 
'''Planning'''
 
'''Planning'''
 +
 +
When the boundary conditions are clear and all parameters marked out, the project team can begin with the planning phase. In this phase all the next steps are described in detail, and are linked to each other. The team leader is pushing the future tasks to the team members.
  
 
'''Design'''
 
'''Design'''
 +
 +
The requirement specification is used to transfer the gathered date into a system design. At the end of this phase the members should know how the product looks like.
  
 
'''Construct'''
 
'''Construct'''
 +
 +
With the input of the last phase, the system design is implemented to the product - the product or service is constructed.
  
 
'''Test'''
 
'''Test'''
 +
 +
After the construction, all the parts have to be tested, so that the customer does not face any trouble.
  
 
'''Turnover'''
 
'''Turnover'''
  
 +
Once the testing is done, the product is released into the market or deployed in the customer environment. After the release it is possible to make modifications to the product/service/system.
  
  
−
==Pros==
+
With the waterfall model, the different sequences and the sequential relationship in mind, it is important to know that in this flow of processes, the tasks are pushed by the team leader to the project team members. Although it's resulting in a higher amount of workload, the tasks are handled step-by-step, even when the result is not used in the next phase anymore.
−
Developers and customers agree on what will be delivered early in the development lifecycle. This makes planning and designing more straightforward.
+
 
−
Progress is more easily measured, as the full scope of the work is known in advance.
+
[[File:Push Process.png|frame|Push Process<ref name="malik"/>]]
−
Throughout the development effort, it’s possible for various members of the team to be involved or to continue with other work, depending on the active phase of the project. For example, business analysts can learn about and document what needs to be done, while the developers are working on other projects. Testers can prepare test scripts from requirements documentation while coding is underway.
+
 
−
Except for reviews, approvals, status meetings, etc., a customer presence is not strictly required after the requirements phase.
+
==Pros==
−
Because design is completed early in the development lifecycle, this approach lends itself to projects where multiple software components must be designed (sometimes in parallel) for integration with external systems.
+
 
−
Finally, the software can be designed completely and more carefully, based upon a more complete understanding of all software deliverables. This provides a better software design with less likelihood of the “piecemeal effect,” a development phenomenon that can occur as pieces of code are defined and subsequently added to an application where they may or may not fit well.
+
*Easy to use and understandable due to documentation for every phase
 +
 
 +
*The team leader is distributing the tasks to the team members - no further training required
 +
 
 +
*Easy to manage and control due to defined structure and deadlines
 +
 
 +
*The agreement between project leader and customer in the early stage of the project life cycle makes the planning more straightforward
 +
 
 +
*Since the full scope of work is known at the beginning, the measurement of progress is easier
 +
<ref name="agile">Agile vs. Scrum vs. Waterfall vs. Kanban, https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban </ref><ref name="wrike"/><ref name="standard"/><ref name="pmi">Lean Project Management, https://www.pmi.org/learning/library/lean-project-management-7364 </ref>
  
 
==Cons==
 
==Cons==
−
Here are some issues we have encountered using a pure Waterfall approach:
+
 
−
One area which almost always falls short is the effectiveness of requirements. Gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development, in my opinion. Customers are sometimes intimidated by details, and specific details, provided early in the project, are required with this approach. In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting.
+
*High workload
−
Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.
+
 
 +
*Difficult to pinpoint everything at the beginning - limited by specific details
 +
 
 +
*Unsatisfied customer due to little involvement and flexibility
 +
 
 +
*Changes are difficult and costly to implement
 +
 
 +
*Given deadlines can cause stress and limited scope of action
 +
<ref name="agile">Agile vs. Scrum vs. Waterfall vs. Kanban, https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban </ref><ref name="wrike"/><ref name="standard"/><ref name="pmi">Lean Project Management, https://www.pmi.org/learning/library/lean-project-management-7364 </ref>
  
 
=Pull Process=
 
=Pull Process=
 +
The purpose of pull planning is to create a project plan with lean principles.<ref name="attrup"/>  In contrast to the waterfall resp. the push process is the pull process defined by an overlapping system. Therefore, the phase has not to be finalized until the next phase starts, the flow between the phases is more interlocked. The pull process is a common process in the lean management philosophy, it helps to avoid waste of time and money.<ref name="standard"/> Additionally, the total workload is smaller due to the elimination of unnecessary tasks and processes.<ref name="attrup"/>
 +
 +
[[File:Pull Process.jpg|frame|Pull Process<ref name="malik">Own image, according to: Malik (2013). Agile Project Management with GreenHopper 6 Blueprints, Packt Publishing</ref> ]]
  
−
LEAN Overview
+
The common definition of the pull process is, that the customer pulls the value from the project team, but not just the customer is pulling, the subsequent is pulling as well. Thereby, the subsequent is giving the impulse and states in this way when the next phases is starting. Typical pull processes can find in the Kanban or in the Scrum methodology and make those models more flexible and reduces the waste.
−
- Define Value
+
In total the pull processes avoid delivering value before the customer or a colleague requests it.<ref name="attrup"/>  In addition, the pull processes avoid the provision of more than the agreed initial scope, it allows the implementation of a just-in-time system.
−
- Map Value Stream
+
−
- Create Flow
+
−
- Establish Pull
+
−
- Pursuit Perfection
+
  
−
"Let the customer pull value from the project team"
+
As distinguished from the push process, whereby the team leader is "pushing" the tasks to his team members, and put in this way work on a "to-do" list, pull processes allow the team members doing the work when they are ready. Hence, pull processes prevents team members from stress and work on results which will be eliminate in a later stage. A big benefit for the project work is, that tasks or items can be prioritized.<ref name="attrup"/> In this way the project manager can work with his team on the right tasks at the right time while reducing wasted time or effort.
−
Not just the customer is "pulling"->
+
  
−
(Der nachfolgende Schritt gibt den Impuls wann es weiter geht)
 
  
−
By adding out of scope functionalities, you can expect that it will impact negatively your project triple constraint. If you make more work than required at a certain time, it will be pilled in waiting to be expedited to the next step. You should also avoid here to execute project management activities in a batch. Indeed if there is any product change request then you would end up with obsolescence and therefore waste.
 
−
[[File:Pull Process.jpg|thumb|The pull process]]
 
−
The challenge here is to avoid delivering value before the customer request it. Also you should not provide to the customer more than the agreed initial scope. In manufacturing, we let the customer pulling the flow by means of a Kanban system. Kanban allows the implementation of a just-in-time system. It uses cards to signal the need for an item by triggering the movement, production, or supply of a unit.
 
 
==Pros==
 
==Pros==
−
It supports the continuous flow of work
+
 
−
Work is done as a team
+
*Supports the continuous flow of work
−
There is a clear indication of state of work
+
 
−
Work in progress is limited for each status
+
*Changes can be also implemented in a later stage of the project without high expenses
−
There is a lesser burden on individual backlog
+
 
−
It allows better planning and prioritization of work
+
*Involvement of customer
−
It allows improved continuous delivery
+
 
−
Kanban system implements the pull model for continuous delivery by eliminating the waste and focusing on continuous improvement.
+
*Allows better planning and prioritization of work
 +
 
 +
*Continuous delivery by eliminating the waste and focusing on continuous improvement
 +
 
 +
*Increase productivity and speed up task delivery
 +
 
 +
*Decrease stress level of project team members
 +
 
 +
*Reduce waste of time and money
 +
<ref name="agile">Agile vs. Scrum vs. Waterfall vs. Kanban, https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban </ref><ref name="wrike"/><ref name="standard"/><ref name="pmi">Lean Project Management, https://www.pmi.org/learning/library/lean-project-management-7364 </ref>
  
 
==Cons==
 
==Cons==
 +
 +
*Qualified employees required to prioritize the right tasks or items
 +
 +
*Too high involvement of the customer can affect the project's success
 +
 +
*No clear deadlines can postpone the project
 +
<ref name="agile">Agile vs. Scrum vs. Waterfall vs. Kanban, https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban </ref><ref name="wrike"/><ref name="standard"/><ref name="pmi">Lean Project Management, https://www.pmi.org/learning/library/lean-project-management-7364 </ref>
  
 
=Waterfall vs. Pull=
 
=Waterfall vs. Pull=
−
Summary pros cons.  
+
 
−
Workload image
+
A main question in the set up of a project plan is how to select the right methodology and process of a project. Thus, the comparison of the waterfall and the pull processes has a high relevance for project managers. There are different types of projects and many factors which play a role in the selection of the project's structuring. In fact there are some guidances for project managers, which can facilitate the decision between a waterfall and a pull process.  
−
[[File:Push vs. Pull Workload.jpg|thumb|Push vs. Pull workload]]
+
 
 +
Firstly, it is important to have a look to the requirements, the aims of the project and the objectives. In addition, the look and the benefits of the final deliverable take into account.  
 +
If the stakeholder expectations are clear, like in the common way of a construction of physical objects, the look, the material, the functions, the aim in general is definite, the work with waterfall processes should be preferred. The tradition sequential relationship between the phases would be beneficial due to the clear structure and the define connection between the different working steps.
 +
If the product itself is not really defined until the end of the project and especially the design and function phase is a flowing process through the project, like in a software product, an app or even a service, a more flexible project plan with pull processes are needed. However, when the development itself is the main factor for choosing the right process, the amount of workload and the associated time and money is the reason why for especially minimum viable products the pull processes are preferred.
 +
 
 +
Secondly, the consideration of the project team, how many people, how qualified they are and in which way they are used to work within a project, is an important factor for choosing the right processes.
 +
If team members are more efficient in a team, where they can share their ideas, change things on the product/service, the pull process should be considered. In this way, members can priorities their own task by themselves and "pull" the project forward.
 +
If straight orders are required by the team members and they prefer a structured plan that accomplishes tasks sequentially, the waterfall process, with its direct commands from the team leader, seems to be the best option. 
 +
 
 +
In conclusion, if the end of the project is clear and understandable and the path to this target is also elaborated, the traditional waterfall model is still an effective way to manage the project. The limited involvement of the customer during the project could be beneficial due to the minimization of changes. On the other hand, the risk of expensive changes in a later stage of the project are enormous and a main factor if the project ends as a success or failure. Therefore, it is not just the consideration of the processes in the project team, it is important to take the level of flexibility of the customer into account. Although, there are a lot of benefits at the pros and cons list of the pull processes and it looks like that to pull the project is definitively better than to push the project forward, we have to mind that the intricacy of the project can reach from simple to high complex. For instance, a big new building cannot be planned and build with a pure pull process plan due to the connection between the different tasks also in the time management. Therefore, in some projects waterfall projects are necessary. At the end, It is still important to plan the projects individually and also to consider a mixture between different types of processes, e.g. push the tasks to the team members at the beginning to set up the requirements, but keep a sphere of influence at the upcoming phases.
  
 
=Annotated Bibliography=
 
=Annotated Bibliography=
 +
Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition: This book delivers a broad understanding of the principles of project management from the starting point. The phases, sequential relationships and different project life cycles are well explained. Unfortunately the different methodologies are just mentioned, but not really discusses in detail.
 +
 +
Attrup et al (2015). Power in Projects, Programs and Portfolios: Achieve project excellence and create change with strategic impact 1st Edition, Djoef Publishing Inc: The principles of project management and how to adapt successfully in different circumstances. For the topic waterfall vs. pull processes to detailed in strategic change, but it gives a good understanding of the importance.
 +
 +
Malik (2013). Agile Project Management with GreenHopper 6 Blueprints, Packt Publishing: Shows a very clear and understandable picture of the different processes within different methodologies.
 +
 
=References=
 
=References=
 +
<references/>

Latest revision as of 18:10, 16 November 2018

Developed by Johannes Eckert


There are many different methodologies of project management, all of them are defined by different principles and processes.[1] A traditional, sequential methodology, is the waterfall model. Within this model, the tasks of the project plan are sequenced and conducted in a linear way, one task must be completed before the next one begins - the process is smooth and continuous, like a waterfall.[2] Therefore, this model is one of the simplest methods.[2] However, the pull process-based methodologies are used to create the whole project plan more efficient and effective, it was created to eliminate confounding factors within the project and to avoid aimless work. Hence, the pull processes are used in the management style of Lean Project Management, typical pull processes can be find in the Scrum and Kanban methodologies.[2] This article provides an introduction to the waterfall methodology, to understand the processes within a project plan in a better way. However, the article provides a comparison of the waterfall process (push process) and the pull process. Therefore, no other methodologies e.g. Scrum and Kanban are explained. After the introduction into both processes, pros and cons are described and the relevance for the practical usage demonstrated. At the end of the article and the comparison section, a short guidance about the right selection of the processes is provided.


Contents

[edit] Importance for Project Management

A project is divided in several phases (except the single-phase project), and five project groups[1].

Sequential relationship[1]


1. Initiating Process Group: Those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase.

2. Planning Process Group: Those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve.

3. Executing Process Group: Those processes performed to complete the work defined in the project management plan to satisfy the project specifications.

4. Monitoring and Controlling Process Group: Those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.

5. Closing Process Group: Those processes performed to finalize all activities across all Process Groups to formally close the project or phase.


The project manager has to combine those groups and phases into a flow and take into account the product or service, his team and the customer.[3] To establish a real customer value the project should set up a scope baseline control, build a communication plan to improve the information flow, asses stakeholder needs and get the commitment of the internal stakeholder.[1] As a result, there are many factors which have to be intertwine to each other. Thus, project managers are inclined to overlook something at the beginning of the project and this is when project wastes start building. It is important to align with the customers to establish the customer value, but if the customer deflects the project team members it will be end in scope creep. As an interim conclusion, the project planning has to consider a lot of things simultaneously, but it is also very important to ponder in which way and rate the steps are executed.[3]

Impact of Variable Based on Project Time[1]

A project life cycle displays typically four characteristics:[1]


1. The costs and staffing level starts at the beginning of the project low, increase when the work is carried out and decrease quickly when the project is going to close.

2. Not all projects describe a typical cost and staffing curve, they may require resources early in its life cycle and therefore higher expenditures.

3. A project starts with a high amount of risk and uncertainty and run low during the ongoing life cycle.

4. The influence to the final product/service starts on an high level with low costs. At the beginning of the cycle the vision can be adjust rapidly and economically, changes at the end of the project will cause high expenses.


With this description of the characteristics of a project life cycle, we can have a look to the different life cycles, which are designed for different purposes.[3] The main difference of the waterfall model and the pull processes is the influence of the stakeholder and the degree of flexibility. Adaptive life cycles keep stakeholders in the loop and let them influence the project in a higher degree than a predictive life cycle (waterfall). Since, the project plan within an adaptive life cycle is more flexible, the costs of changes are lower.[1]

The importance to think about the way how to execute the project and how flexible and influenceable it should be is enormous. Therefore, the following chapters will provide some clarity about the choose of the right type of process.

[edit] Waterfall Process

The waterfall model (also known as predictive life cycle or fully plan-driven)[1] is made of a waterfall process, which is defined by sequential relationships. A phase, consisting generally all five process groups, starts only when the previous phase is complete. This approach reduces uncertainty within the project life cycle, but it requests a high amount of tasks. As a result, this process is defined by a huge workload. In addition, the project scope, and the time and the cost required to deliver that scope, are determined at the beginning of the project life cycle. Therefore, the project is inflexible and changes are related to high costs.[1]

The waterfall sequential model[4]

The waterfall model is preferred when the product or service to be delivered is well understood. The following phases describe the waterfall model:


Requirements

Firstly, the project team need an understanding of the project's function, purpose etc, the specifications of the input and output of the final product or service are studied and marked.

Feasibility

In the feasibility phase, the target is about finding out all the potential problems. The problems should be evaluated and analyzed and considered for the decision making process.

Planning

When the boundary conditions are clear and all parameters marked out, the project team can begin with the planning phase. In this phase all the next steps are described in detail, and are linked to each other. The team leader is pushing the future tasks to the team members.

Design

The requirement specification is used to transfer the gathered date into a system design. At the end of this phase the members should know how the product looks like.

Construct

With the input of the last phase, the system design is implemented to the product - the product or service is constructed.

Test

After the construction, all the parts have to be tested, so that the customer does not face any trouble.

Turnover

Once the testing is done, the product is released into the market or deployed in the customer environment. After the release it is possible to make modifications to the product/service/system.


With the waterfall model, the different sequences and the sequential relationship in mind, it is important to know that in this flow of processes, the tasks are pushed by the team leader to the project team members. Although it's resulting in a higher amount of workload, the tasks are handled step-by-step, even when the result is not used in the next phase anymore.

Push Process[5]

[edit] Pros

  • Easy to use and understandable due to documentation for every phase
  • The team leader is distributing the tasks to the team members - no further training required
  • Easy to manage and control due to defined structure and deadlines
  • The agreement between project leader and customer in the early stage of the project life cycle makes the planning more straightforward
  • Since the full scope of work is known at the beginning, the measurement of progress is easier

[6][2][1][7]

[edit] Cons

  • High workload
  • Difficult to pinpoint everything at the beginning - limited by specific details
  • Unsatisfied customer due to little involvement and flexibility
  • Changes are difficult and costly to implement
  • Given deadlines can cause stress and limited scope of action

[6][2][1][7]

[edit] Pull Process

The purpose of pull planning is to create a project plan with lean principles.[3] In contrast to the waterfall resp. the push process is the pull process defined by an overlapping system. Therefore, the phase has not to be finalized until the next phase starts, the flow between the phases is more interlocked. The pull process is a common process in the lean management philosophy, it helps to avoid waste of time and money.[1] Additionally, the total workload is smaller due to the elimination of unnecessary tasks and processes.[3]

Pull Process[5]

The common definition of the pull process is, that the customer pulls the value from the project team, but not just the customer is pulling, the subsequent is pulling as well. Thereby, the subsequent is giving the impulse and states in this way when the next phases is starting. Typical pull processes can find in the Kanban or in the Scrum methodology and make those models more flexible and reduces the waste. In total the pull processes avoid delivering value before the customer or a colleague requests it.[3] In addition, the pull processes avoid the provision of more than the agreed initial scope, it allows the implementation of a just-in-time system.

As distinguished from the push process, whereby the team leader is "pushing" the tasks to his team members, and put in this way work on a "to-do" list, pull processes allow the team members doing the work when they are ready. Hence, pull processes prevents team members from stress and work on results which will be eliminate in a later stage. A big benefit for the project work is, that tasks or items can be prioritized.[3] In this way the project manager can work with his team on the right tasks at the right time while reducing wasted time or effort.


[edit] Pros

  • Supports the continuous flow of work
  • Changes can be also implemented in a later stage of the project without high expenses
  • Involvement of customer
  • Allows better planning and prioritization of work
  • Continuous delivery by eliminating the waste and focusing on continuous improvement
  • Increase productivity and speed up task delivery
  • Decrease stress level of project team members
  • Reduce waste of time and money

[6][2][1][7]

[edit] Cons

  • Qualified employees required to prioritize the right tasks or items
  • Too high involvement of the customer can affect the project's success
  • No clear deadlines can postpone the project

[6][2][1][7]

[edit] Waterfall vs. Pull

A main question in the set up of a project plan is how to select the right methodology and process of a project. Thus, the comparison of the waterfall and the pull processes has a high relevance for project managers. There are different types of projects and many factors which play a role in the selection of the project's structuring. In fact there are some guidances for project managers, which can facilitate the decision between a waterfall and a pull process.

Firstly, it is important to have a look to the requirements, the aims of the project and the objectives. In addition, the look and the benefits of the final deliverable take into account. If the stakeholder expectations are clear, like in the common way of a construction of physical objects, the look, the material, the functions, the aim in general is definite, the work with waterfall processes should be preferred. The tradition sequential relationship between the phases would be beneficial due to the clear structure and the define connection between the different working steps. If the product itself is not really defined until the end of the project and especially the design and function phase is a flowing process through the project, like in a software product, an app or even a service, a more flexible project plan with pull processes are needed. However, when the development itself is the main factor for choosing the right process, the amount of workload and the associated time and money is the reason why for especially minimum viable products the pull processes are preferred.

Secondly, the consideration of the project team, how many people, how qualified they are and in which way they are used to work within a project, is an important factor for choosing the right processes. If team members are more efficient in a team, where they can share their ideas, change things on the product/service, the pull process should be considered. In this way, members can priorities their own task by themselves and "pull" the project forward. If straight orders are required by the team members and they prefer a structured plan that accomplishes tasks sequentially, the waterfall process, with its direct commands from the team leader, seems to be the best option.

In conclusion, if the end of the project is clear and understandable and the path to this target is also elaborated, the traditional waterfall model is still an effective way to manage the project. The limited involvement of the customer during the project could be beneficial due to the minimization of changes. On the other hand, the risk of expensive changes in a later stage of the project are enormous and a main factor if the project ends as a success or failure. Therefore, it is not just the consideration of the processes in the project team, it is important to take the level of flexibility of the customer into account. Although, there are a lot of benefits at the pros and cons list of the pull processes and it looks like that to pull the project is definitively better than to push the project forward, we have to mind that the intricacy of the project can reach from simple to high complex. For instance, a big new building cannot be planned and build with a pure pull process plan due to the connection between the different tasks also in the time management. Therefore, in some projects waterfall projects are necessary. At the end, It is still important to plan the projects individually and also to consider a mixture between different types of processes, e.g. push the tasks to the team members at the beginning to set up the requirements, but keep a sphere of influence at the upcoming phases.

[edit] Annotated Bibliography

Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition: This book delivers a broad understanding of the principles of project management from the starting point. The phases, sequential relationships and different project life cycles are well explained. Unfortunately the different methodologies are just mentioned, but not really discusses in detail.

Attrup et al (2015). Power in Projects, Programs and Portfolios: Achieve project excellence and create change with strategic impact 1st Edition, Djoef Publishing Inc: The principles of project management and how to adapt successfully in different circumstances. For the topic waterfall vs. pull processes to detailed in strategic change, but it gives a good understanding of the importance.

Malik (2013). Agile Project Management with GreenHopper 6 Blueprints, Packt Publishing: Shows a very clear and understandable picture of the different processes within different methodologies.

[edit] References

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition. Newtown Square, Pennsylvania: Project Management Institute, Inc
  2. ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 Project Management Methodologies, https://www.wrike.com/project-management-guide/methodologies/
  3. ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 Attrup et al (2015). Power in Projects, Programs and Portfolios: Achieve project excellence and create change with strategic impact 1st Edition, Djoef Publishing Inc
  4. ↑ Own image, according to: Project Management Institute (2013). A Guide to the Project Management Body of Knowledge (PMBOK® guide) 5th edition. Newtown Square, Pennsylvania: Project Management Institute, Inc
  5. ↑ 5.0 5.1 Own image, according to: Malik (2013). Agile Project Management with GreenHopper 6 Blueprints, Packt Publishing
  6. ↑ 6.0 6.1 6.2 6.3 Agile vs. Scrum vs. Waterfall vs. Kanban, https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban
  7. ↑ 7.0 7.1 7.2 7.3 Lean Project Management, https://www.pmi.org/learning/library/lean-project-management-7364
Retrieved from "http://wiki.doing-projects.org/index.php?title=Waterfall_vs._Pull_Processes&oldid=60217"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox