Waterfall vs. Pull Processes
(→Pros) |
(→Cons) |
||
| Line 54: | Line 54: | ||
==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. | ||
| + | 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= | =Pull Process= | ||
Revision as of 23:47, 25 February 2018
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.
Contents |
Importance for Project Management
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:
Establish real Customer Value: Set 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.
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.
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
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)
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.
Pros
Cons
Waterfall vs. Pull
Summary pros cons. Workload image
