Changes in the world of project management don’t mean it’s splitting in two, but the evolution of agile approaches gives project managers a potent option that is significantly different from legacy waterfall approaches.
The two approaches are mirror images. The traditional waterfall approach is highly structured. A plan is created and followed until its conclusion. Agile approaches are self-correcting and far more open and iterative. Whether bridges can be built and hybrids created or if organizations must choose between the two still seems unclear.
Villanova lays out the steps in waterfall project management. It moves methodically from the initial study, analysis and definition of the project and its goals to the eventual management and maintenance of the finished product.
Agile, as the name implies, flows more freely. Projects are carried out in small bits amidst constant feedback for assessment and, if necessary, course correction. It even sounds a bit “new age-y,” at least as described by the Association for Project Management:
Agile project management is an approach based on delivering requirements iteratively and incrementally throughout the project life cycle. At the core of agile is the requirement to exhibit central values and behaviours of trust, flexibility, empowerment and collaboration.
Different Approaches, Different Goals
Agile was formalized in 12 principles laid out in the “Manifesto for Agile Software Development” in 2001. Kelley O’Connell, PMP, the Agile Coach at Lincoln Financial Group, used the development of the first iPhone as an example of the value of agile. “They had a list of requirements: They took out some of things in the first iPhone because the amount of time they wanted to spend doing it. They took out features such as the front-facing camera and cut and paste.”
That, she said, was an agile approach. Apple got the product out faster and, through the feedback it gathered, kept in the features that were most important. If the company had used a waterfall approach, she said, the device would not have been released until all the original features were included even if the value of some had faded.
The value of this approach is tied to the Pareto Principle, named for economist Vilfredo Pareto, who introduced the concept while at the University of Lausanne in 1896. Also called the 80/20 rule, it states that across many endeavors, 80 percent of the effects are caused by 20 percent of the causes. The idea behind agile project management is simply to continually seek to find the most useful 20 percent.
At the beginning of the design process of a car, for instance, five features may be given equal weight. In an agile environment, the continual feedback loop may lead to three being put on the back burner. That ability to adjust on the fly is absent in the waterfall approach.
The challenge to the agile approach is that it can be difficult to keep focus when the goals are by design fluid and changing. The process must be carefully managed. If not, what starts as continual refinement and perfection morphs into drift. “Because the scope isn’t locked in, you have to be more diligent in project reporting to make sure you are hitting required timelines and deadlines,” O’Connell said.
A related challenge is that organizations may resist paying for projects without clearly defined objectives and timelines. “People who are successful in large organizations who make decisions are generally not comfortable with the idea of improving over time, making mistakes and being transparent in mistakes,” said Doug Rose, PMP, the author of “Enterprise Agility for Dummies.”
The Case for Waterfall
Waterfall approaches have the diametrically opposite issues. A highly structured approach may do a better job of herding cats toward a project’s completion within schedule and budget constraints. At the same time, however, the result sought when the project was developed may not be what provides the highest possible business value to the organization.
There, of course, are situations in which the waterfall approach is perfectly appropriate. “There are absolutely great projects with waterfall,” Rose said. “If when you start your project you are absolutely clear about what you want when you finish the project, [waterfall is a good choice]. There are projects in which you don’t want to pivot. Sometimes government projects are like that. The government allocates a certain amount of money and spends a number of years coming up with requirements. In those projects, you build exactly to what the expectations are.”
It seems logical to ask whether it is possible to combine the two. The chances of effectively doing this are not agreed upon. Mike Goss, PMP, a project management trainer and principal of Goss Consulting, has a warning. “Beware of the pit of doom known as the waterfall-versus-agile debate,” he wrote in response to emailed questions from IT Business Edge. “It is similar to the conversations between Trump-lovers and Trump-haters. [They are] passionate conversations that lead nowhere, because everyone talks and no one listens.”
Despite that warning, Goss thinks that the two approaches can coexist. “Since all projects have portions which are predictable, and portions which aren’t predictable, it makes sense to have processes to handle both situations,” he said. “Use waterfall processes for the predicable portions of your project. Use agile processes for the unpredictable portions.”
Rose is skeptical that the two be reconciled. “There are a lot of companies that market those but I think that it is very difficult to have a hybrid approach…The buffer zone between having detailed plans and being able to pivot and adapt is very difficult for most organizations [to maintain],” he said. “I don’t know that I’ve seen anyone do it that well.”
The approaches together broaden the way in which project managers can help their organizations achieve goals. The bottom line, though, is that they are significantly different approaches that seem to have diametrically opposite philosophies and therefore different strengths and weaknesses. That clearly means that organizations must be careful in which one they choose.
Carl Weinschenk covers telecom for IT Business Edge. He writes about wireless technology, disaster recovery/business continuity, cellular services, the Internet of Things, machine-to-machine communications and other emerging technologies and platforms. He also covers net neutrality and related regulatory issues. Weinschenk has written about the phone companies, cable operators and related companies for decades and is senior editor of Broadband Technology Report. He can be reached at cweinsch@optonline.net and via twitter at @DailyMusicBrk.
