Have you just been hired on as a project manager, but you’re not sure what approach you would like to take on the next project? You’re not alone in this position.
The first question many project managers have when they first begin a project is “where exactly do I begin?”
Whether you’ve been a project manager for years or this is your very first project, you’ll want to figure out which method you would like to use to execute this project. You’ll want to do this fast.
There are many methodologies to approaching the project that you will manage. For instance, you may use a waterfall approach, Lean, Kanban, or Scrum, or you may come up with a hybrid method of your own. (Manage This podcast episode 66 covers Is Agile Right for Me?)
The two most common and effective methods of approaching project management are the agile method and the waterfall method. (Velociteach has both online and instructor-led courses related to both topics. For online resources, check out our online Fundamentals of Agile course and our Introduction to Project Management Fundamentals course; for instructor-led classes, see our Project Management Fundamentals course and Agile Project Management course descriptions for more information.)
Here we will help you figure out the intricacies of each method and which methodology is right for you and your project.
What is Waterfall Project Management?
First, let’s take a look into a long tried and true methodology: the Waterfall method.
The waterfall project management method has been around for many decades. It’s a straightforward, direct approach that follows a rigid structure. It involves lots of up-front planning and mapping out a distinct and specific timeline for when things will be accomplished in sequence. The next task cannot begin until the first one is finished, and so on.
It’s sort of like how you level up in video games. You can’t reach the next level until you have completed what you need to for the previous one.
One example of this step-by-step process of waterfall project management is as follows:
- Requirements: The project manager and team gather all of the documents necessary for the project and determine the requirements of the project.
- Design: Next, the project manager and team design the model for the workflow of the project. They build the project management plan.
- Implementation: The project plan is put into practice, and the team executes the work of the project.
- Testing: The individual elements of the product or service are tested to ensure that they work efficiently and fulfill their requirements.
- Deployment/Delivery: The product or service is launched.
- Maintenance: Your team performs basic upkeep and maintenance of the product or service with the plan of transitioning that maintenance to another department or to the customer.
Other waterfall examples include the Process Group approach defined in the PMBOK Guide, which involves 5 areas: Initiate, Plan, Execute, Monitor & Control, and Close.
Straightforward and simple, right?
When is it Best to Use the Waterfall Methodology?
So, when would you want to use this methodology in project management?
The waterfall methodology is most effective when the project work is predictable – in fact, another name for the waterfall method is “predictive.” And, the waterfall approach works well when the scope is well-defined. Construction projects are prime examples.
Pros of the Waterfall Method
There are a few obvious pros of the waterfall method.
It’s simple and straightforward. You go from point A to point B to point C. It’s also great for project managers who prefer to do a lot of planning ahead of time.
It also can be easily replicated and used as a blueprint for future projects, making things easier down the line.
Simply put, the waterfall method is the easiest to understand. The team uses historical information to create a predictable approach to the project work. They carry out the plan in phases, and the project results in a big deliverable or result at the conclusion.
Cons of the Waterfall Method
A weakness in following this project management method is that the waterfall approach discourages the customer or key stakeholders from making significant changes during project execution. You agree to a scope, stick to it, and resist change to that scope.
When you’re in the middle of managing a project, sometimes things can change. It’s important for you, as the project manager, to be able to roll with the punches. The waterfall method to project management resists the notion of changing things as you go.
Another drawback to this predictive method is that the team often makes one big delivery at the end of the project. The long project work culminates in the great unveiling of the finished product. In some cases, the project team nailed it, and the customer rejoices. In other cases, the customer is disappointed and left wishing for more frequent feedback throughout the life of the project.
Overall, the waterfall method is considered less effective for projects that require frequent small deliveries and a steady flow of feedback. Certainly, in cases where the project scope is not clear, this waterfall approach can lead to problems.
What is Agile Project Management?
Now let’s take a look at agile project management. Most of the modern software and programming projects use this method, and there are a few reasons for its widespread success.
The agile methodology was launched back in 2001 by 17 technologists who created the agile manifesto. The four major principles of this methodology with regard to a common goal of developing better software are:
- Placing importance on individuals and interactions over tools and processes
- Working software over comprehensive documentation
- Collaboration with customers over negotiating contracts
- Actively responding to changes over following a set plan
As you can see, it’s quite different from the waterfall methodology in multiple ways.
The emphasis is put on innovation, cooperation, and pivoting when necessary. As technology has changed, our approach to managing projects has had to change with it. The agile method does take some training to understand the intricacies of how it works in practice, but it creates better results for computer software and other projects that don’t fit well with the heavy emphasis on upfront planning that waterfall requires.
This process always begins with the user in mind. Who will this software be used by? What are they needing right now, and how can we make it available, accessible, and easy to use for them?
The agile approach includes a key role that is not commonly found in waterfall projects – that role is the product owner. This individual represents the business interest of the final users of the product being developed. Importantly, the product owner defines and prioritizes the features of the product that the project team will develop.
The product owner works with a development team (or teams) to tackle individual parts of the challenge alongside each other, simultaneously. These development teams feature a diverse group of specialists who work on individual parts of the software, then collaborate with each other to get the end result.
When is it Best to Use This Methodology?
The agile method has become a very popular approach because of the flexibility and emphasis on delivering value early and often. Agile methods are iterative, adaptive, and incremental. The team performs short bursts of work (sprints or iterations) that may last from a week to four weeks. At the end of that work period, the team demonstrates a working solution. The delivery of the project outcome is considered incremental, meaning that additional functionality should be added at the end of each iteration that adds to the value of the product.
This agile approach is adaptive. Where the waterfall team needs to nail the scope up front, the agile team is more flexible – they only need the scope well-defined for the upcoming iteration or work period. Waterfall resists change. Agile welcomes change. So, if the project environment has a lot of scope uncertainty, agile may be the better approach.
The best agile teams are made up of generalizing specialists – these are team members who have broad knowledge and experience in a number of areas. For example, Patricia may be a Java coder and know SQL well, but she is also experienced in writing test cases. That’s great for an agile team – Patricia can help other team members because of her diversity of skills and experience.
Pros of the Agile Method
Agile methods are particularly effective when the customer needs to get the product to market quickly and make frequent updates to it after the launch. For example, think of an app or software that starts with simple functionality. Once the owner of the software measures user response, that owner decides which features to drop, add, or modify. Agile is well-suited for this type of product development project.
The agile method’s best quality is that it’s more adaptable than its waterfall predecessor. In the previous method, you couldn’t afford to pivot (cost-wise and time-wise) or make changes to the game plan. You had limited wiggle room.
With the agile method, you can break sets of features into planned releases and target those by iterations. The product owner prioritizes those features based on the value they will bring.
The nature of agile teams builds in feedback loops and accountability, requiring each individual on the team to contribute, and take responsibility for, their own unique work.
Cons of the Agile Method
Though it has many benefits, there are some disadvantages to the popular agile methodology.
For one, the agile method is well-suited for developing products that can be redeployed, updated, and refreshed with ease. As such, agile lends itself well to information technology projects, software development, etc. For those projects that require heavy investment in materials (steel, concrete, etc.), agile is not the best approach. Yes, members of the team may take an agile approach to early planning for a construction project. However, when it comes time to order materials, the plans must be fully thought out, vetted, and complete. An agile team cannot “redeploy” or “deliver an update” to a soccer stadium or bridge.
An agile approach may not fit the desires of the customer or the expectations of management. The adaptive nature of agile may go against the culture of the performing organization. The approach selected by the project manager must fit the environment, and agile does not always fit.
Which One Fits Right for You?
In order to determine which of these two methodologies is right for you and your project, you must consider the requirements and circumstances of the project as well as your own personal knowledge of how you manage best.
When choosing the right approach, the project manager has a number of factors to consider. A few factors include the culture of the organization, the frequency of deliveries, the team’s experience with both methods, the size of the team, and the nature of the product or service that the project will produce. PMI Fellow Eric Norman created an online course that dives deeper into this topic called How To Know When Agile Isn’t the Right Tool for the Job.
If you need to learn even more about each of these methods to determine which may be a better fit, check out the online courses offered by Velociteach to learn everything you need to know before determining which methodology is right for this project. In addition, Velociteach offers several live, instructor-led courses that will get your team on the same page and speaking a “common language”, whether you choose Waterfall or Agile.
Sources:
What the Waterfall Project Management Methodology Can (and Can’t) Do for You | Lucidchart
What is agile methodology? Modern software development explained