Waterfall vs. Pull Processes
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 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. 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. For the comparison of the two different processes are pros and cons described and the relevance for the practical usage demonstrated.
Contents |
Importance for Project Management
A project is divided in several phases (except the single-phase project), and five project groups.
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.
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.
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 phases into a flow and take into account the product or service, his team and the customer. 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. 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 is deflect 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.
A project life cycle displays typically four characteristics: 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. 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 a adaptive life cycle is more flexible the costs of changes are lower.
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 process styles.
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. -> Push
The waterfall sequential model... 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. 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.
Requirements
Feasibility
Planning
Design
Construct
Test
Turnover
Pros
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. 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. 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.
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. 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.
Pull Process
Overlapping
LEAN Overview - Define Value - Map Value Stream - Create Flow - Establish Pull - Pursuit Perfection
"Let the customer pull value from the project team" Not just the customer is "pulling"-> (Der nachfolgende Schritt gibt den Impuls wann es weiter geht)
Kanban + Scrum
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.
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.
Unlike a “push” system, where work is given to a person and put onto a massive “to-do” list, pull systems allow the person doing the work to pull in tasks as they are ready. This prevents people from feeling overloaded and forces teams to prioritize. This means that project managers and team members can focus on the right tasks at the right times while reducing wasted time or effort. Kanban control systems can significantly increase productivity and speed up task delivery.
The purpose of pull planning is to design a project-based production system in conformance with lean principles. Like all aspects of Last Planner, it is a collaborative approach that includes those who are directly responsible for supervising the work on the project. People mistake merely scheduling a phase of work from the end working backwards for the intent of pull planning. One of the keys to success in designing a production system based on lean principles is to get all of the work experts who are supervising the work, we call them last planners, to engage with each other to collaboratively work out a plan for the phase that includes the best of the alternatives available to them. Facilitating that conversation can be a challenge if you aren’t starting out with the right question. What question?
Pros
It supports the continuous flow of work
Work is done as a team
There is a clear indication of state of work
Work in progress is limited for each status
There is a lesser burden on individual backlog
It allows better planning and prioritization of work
It allows improved continuous delivery
Kanban system implements the pull model for continuous delivery by eliminating the waste and focusing on continuous improvement.
Cons
Waterfall vs. Pull
Summary pros cons. Workload image
