Time is money, so it’s important to complete tasks efficiently and organize teams to work optimally to achieve goals. No matter what process you use, the most efficient way to do this is through project management. With project management, processes are kept on track and everyone involved is aware of each individual’s responsibility.
The best style of project management is still up for debate. Traditional project management and agile project management are two contrasting styles that are often pitted against each other, each with unique values and downfalls.
The best methodology to use for a specific project largely depends on the nature of the project and its requirements. Consequently, it’s important to understand the premise of each of these styles and the attributes that differentiate them.
Traditional Project Management
The traditional, phased approach to project management has been implemented by companies and organizations for years. The most well-known is the waterfall method, which is best used in situations where there are clear goals and not many changes are expected to happen.
Waterfall is a set method that doesn’t change much depending on the project and relies heavily on upfront planning. It also trusts that every team member involved knows exactly what they’re doing and is able to do it in the allotted time. All phases of a process occur in a sequence, and once one milestone is achieved, the next can begin.
There are limited budget and timeline flexibilities, which can sometimes be a big problem, but there is also a great deal of documentation and accountability. If a project needs any change, even a minor one, a phased approach makes it quite tedious.
Agile Project Management
Agile methods differ from traditional methods in that they prioritize feedback and learning, promoting flexibility and collaboration. Instead of a set process, they allow room for a constantly revised and updated plan of action based on outcomes, customer feedback, and latest results.
Of course, there is an outline and a plan in place, but work is broken down into sprints, which are small, time-boxed segments that aren’t necessarily required to be carried out in order. It is used principally for software development projects, since the nature of those projects requires a team effort.
Agile is essentially adaptive and allows each member of the team to contribute to the decisions that need to be made along the way and to influence the direction of the project. Agile relies on the individual team members and their expertise and commitment to the project, rather than on processes. It also is more flexible and has a relaxed approach to changing variables, such as schedules and cost.
The rigid structure of the traditional process means that there is little room for flexibility once the process has been started. Any possible changes or variables must be accounted for in the upfront planning; otherwise, they will cause massive disruptions to the top-down process, and the project will be hindered. Everyone involved in the process must stick to their designated role as best they can, and change is usually discouraged, since productivity will pay a huge price.
With agile project management, the process is much more flexible, as team members are free to experiment or question the plan if they think it necessary. Changes can be made to the process and the product at any stage of the project. Communication and creativity are encouraged in order to find the most beneficial alternatives and factor in any new information.
Working with agile means the developers have the freedom to use their expertise to influence and improve the project outcome.
With traditional methods of project management, the project manager has worked on all the initial planning, oversees the entire process, delegates work to team members, and dictates the inflexible, structured method. Team members generally don’t get a say in the direction of the process, which is why the project manager is seen to be solely responsible for the entire journey of the project and has complete ownership.
Alternatively, agile project management offers a more shared responsibility for the project. The team members all have accountability for various parts of the project, and therefore each member also has ownership. All team members are able to adapt the plan and work as necessary throughout the project.
Agile methods require team members to collaborate to come up with a plan, and it’s expected to have frequent input and updates from everyone involved. Agile provides a higher level of transparency during the process, since all members are aware of the entire plan and are kept updated on what everyone is working on. Having higher levels of accountability for a project is also shown to improve engagement and motivation.
Traditional waterfall methods of project management are best implemented for less complex projects that have few dependent variables and expect few changes. If a project has a clear and defined goal and the project manager knows exactly the amount of resources, time, and effort needed to achieve it, then the traditional method will provide the most efficient way to complete that project.
The agile method is a great option for more complex projects with many overlapping or interconnected components. When a project has many variables that could switch up or there is the potential for feedback or learning within the project that may affect the outcome, then agile is the more appropriate medium to work with.
Choose What’s Best for Each Situation
There is no specific answer for which method of project management is objectively best, since they each have their merits and are suited to different styles of project. What is most important is that managers understand the nature and requirements of their project, as well as the capabilities and experience of their team. Once all aspects are considered, it’s up to them to decide which is the best method to implement for a specific project.
Which method of project management businesses should use largely depends on the type of project, its complexity, and the desired outcome. The main thing that’s important with project management is your team completing their tasks as efficiently as possible, so there’s no cookie-cutter method for that to happen every time; this is why so many different methods of project management exist.
Successful companies don’t enforce a one-size-fits-all policy. Instead, they incorporate all methods of project management to solve different problems and achieve different goals.
You would also use waterfall for safety critical systems which may be complex.
I think if the system really doesn't do much other than collect data and display data, input output and the focus is just on a nice user front end interface, Agile is a good choice.
If there is any complexity and there are processes that follow a workflow and later processes have dependencies from earlier processes, you really need to put thought into requirements and design and waterfall is clearly better.
To redo, code and test, over and over because you focused on sprint 1 and 2 which have dependencies on sprint 7 and you didn't think anything through is reckless and a complete waste of time. If you had a hybred approach where you did enough of the design to build a backlog that was basically execution of coding and the requirements and design was done with a waterfall approach, having the coding done in agile would work, but to build a straw man backlog in sprint 0 with no meat is a disaster waiting to happen.
In general I do agree with the article. Thank you.
In project management however we have been aware of the principle of tailoring for a long time already. So, the question is not which pm method is best but which combination of methods solves the problem both most efficiently as well as most effectively. There is no general recipe.
What keeps annoying me is the use of the word waterfall. Fitfy (yes, 50!) years ago Winston W. Royce published a paper: "Managing the Development of Large Software Systems" (IEEE, Wescon). In that paper Royce depicted a chart that looked like a waterfall, though he never mentioned that term. And below that figure Royce stated explicitely: "I believe in this concept, but the implementation described above is risky and invites failure." Then Royce continues to explain less risky implementations and they contain everything that is at the core of today's pm methods: feedback cycles, iterations etc.
Iow: there is no such thing as a waterfall method! No method, not even the ones prior to Royce were or are one-way. Somebody unfortunately invented waterfall, contrary to better knowledge! And thus reinforces the insane and unnecessary 'Agile vs Waterfall' discussion.
Let's step a few inches back und do what we should do anyway: use best or at least good practices, no matter where they come from.
This is an excellent and often-forgotten point. The "waterfall method" is a strawman that is only used by very naive project managers.
Agile is more expensive. Too many redos because of requirements and design are just not thought through enough because of the nature and pace of sprints. You get to sprint 7 and you have to redo sprint 1 and 2 because the functionality later in a process had dependencies that were not defined well enough because the complete design of the system was not throught though well enough.
Than there is the nature of breaking things up in these small pieces that requires the same processes to be tested over and over.
It is like going out to the mail box and there are 10 letters and instead of getting all 10 letters you go out there and get them 1 at a time.
I guess there's always this problem between choosing traditional and Agile project management so I'm glad you write about it. But I don't agree that Agile is dedicated to these more complex projects only. When you start your journey with Agile, it's definitely better to use it in case of simpler projects to understand its features fully. When I was introducing a new team to Agile and Kanban, they were really sceptical about the WiP rule (https://kanbantool.com/kanban-guide/kanban-fundamentals/limit-work-in-pr... ). I tried to show them how it works in case of quite complicated process and my explanation was a total failure. Only when we used a simpler project as an example, it was clear and doable to implement this rule for them. So flexibility is needed in this area too, I think.
With agile methods, team members have to work together to come up with a plan, and everyone is expected to give input and updates often. Agile makes the process more open, since all team members know the whole plan and are kept up to date on what everyone is working on. Having more responsibility for a project has also been shown to make people more engaged and motivated.
Clients and decision makers are actively involved in initiation, planning, review and testing. In the traditional approach, the project manager holds the reins of the project.