Before delving into a project, many decisions need to be made: From scope to resources to timeline. There is also the question of methodology. Should you use agile or follow the familiar waterfall approach?
That’s a tricky question. And depending on who you ask, you’ll get different answers. In this article, we will look at the question from a real-world perspective. And we’ll share with you some criteria that we believe should be driving your decision.
But before explaining the characteristics of each methodology, let’s briefly discuss the importance of this decision.
Why does the choice of methodology matter?
Put simply, project methodology describes the way a project is managed. How you structure a project. The documents that are being used. How you go about collecting requirements. What meetings and workshops you have. How you involve the client and so on.
Depending on your project, there is a method that best suits that specific project. And if you don’t put any thought into the methodology question and pick an approach that is not ideal in your case, your project may face big challenges to deliver the expected result for the client, within the timeframe and budget agreed.
Agile vs. Waterfall – The difference between the two approaches
The Waterfall Approach
The waterfall methodology, considered to be a traditional method, is made up of several phases, each taking place one after another in a logical sequence. A basic template for this is:
- Requirement analysis
- Design/Concept
- Implementation
- Testing
- Review
- Rollout of final product
There are a few main characteristics of this methodology that set it apart from the agile method. First of all, the scope is fixed from the beginning on. This means there is a clear list of things the project must provide. Using the initial scope, detailed requirements are given upfront, meaning that clients and project managers have discussed and agreed upon what will be delivered and when. This makes planning straightforward and easily measurable.
Secondly, each phase must be completed before the following stage can begin. This aspect of waterfall makes it much easier to manage the project. In theory, an organized plan leads to a smooth production process and therefore a happy project team and client.
So, what are the pros and cons of waterfall? Some of the main benefits are a structured and straightforward plan, easily measurable progress, and pre-defined stages that require customer involvement. Project managers can communicate early on as to when the customer would need to be involved. This makes it easy for the client to plan their work.
The biggest problems with waterfall can be the gathering of ineffective and inaccurate upfront requirements, management of unexpected changes, and delay in delivering of the final product, which usually leads to customer disappointment. In the real world, it is hardly possible to know all the requirements at the beginning of a project. This can make it hard for the project team to have a clear picture of what the customer wants and needs. Because requirements must be given upfront, customers may not know exactly what they want and need, and the customer team may not be able to visualize every detail that early on. This can result in a final product that is not exactly what was desired or has missing features. This is one of the biggest drawbacks of waterfall; changes and additions cannot easily be accommodated along the way.
The Agile Approach
The agile methodology was created on the basis of waterfall’s limitations. In the 1990s, a group of developers began experimenting with different project management methodologies, creating development methods like Scrum. These were some of the earlier developments of agile, which were established in the early 2000s through something called the Agile Manifesto (click to read it). This was essentially the product of 17 project managers coming together to create an efficient and customer-based development methodology. The manifesto covers the four key values:
- Individuals and interactions over processes and tools: the project manager should prioritize collaboration and customer input instead of sticking to fixed rules that may be outdated.
- Working software over comprehensive documentation: even though this principle is related to software, it can be applied to any other field. It essentially means that the project team should focus on delivering a working product that the customer can use (even though it may be incomplete), instead of trying to build the “perfect” solution that may never be delivered because realization turns out to be too complicated.
- Customer collaboration over contract negotiation; instead of being focused only on details stated in a contract, try to find a solution together with the customer.
- Responding to change over following a plan; project managers should adapt to changes, instead of sticking to an outdated plan.
So, what is the typical structure of an agile project? Well, since adjustments can be made after each phase, there is no set structure. Oftentimes, a project activity may look like this:
- Design
- Develop
- Test
- Design
- Develop
- Reiterate
- And so on, until the developer and customer are satisfied with the product
This makes the agile approach a very iterative and team-based approach. For an agile project, there is no fixed scope, just a timeline and a budget based on the requirements prioritized by the client. Typically, a project will be divided into so-called “sprints”, which are like mini-projects that are carried out one after the other, each sprint taking usually one or several weeks. And in each sprint, the project team goes through the same cycle of activities shown above.
There are many advantages to the agile method, starting with the fact that customers are involved in every step early on in the project. This helps to ensure that the final result ends up being what the customer is really looking for. Also, the agile approach is more flexible when it comes to handling change (i.e. when features are added, removed, or when their priorities change), which improves the quality of the project result.
The main challenges with the use of the agile approach stem from leadership and the team. The agile methodology requires high levels of organization within a team. As discussed above, the agile approach is more collaborative. Therefore it requires a certain type of people.
The project team must contain high levels of an organization, employee empowerment, attention to detail, mutual trust amongst all team members, self-sufficiency and clear communication. If a project team doesn’t have these crucial characteristics, then it is likely that the agile project will not deliver the expected benefit for the client.
Choosing Between Agile and Waterfall: Four Criteria to Find The Right Approach for a Specific Project
As discussed above, both agile and waterfall provide a team with benefits and drawbacks. So how should you decide which method to use in a specific project? We have discussed this question with other project managers. Using the feedback received, we put together a list of (currently) four criteria that should help you decide which approach will best suit a specific project.
The criteria are:
- Client type
- Scope type
- Project type
- Client availability
These criteria should not be evaluated individually, but rather in combination. That means for a specific project you should take into consideration all criteria combined in order to make a decision for a specific methodology.
Important note: We believe that you can’t make a methodology decision purely from a “technical” standpoint, where you only look at the type of work involved and the subject matter the project is concerned with. You must also look at the people and the organization involved. These are more “soft” or cultural factors, which have a tremendous effect on the success of projects in general. For these reasons, we will provide you with a more nuanced opinion on the methodology question than you might find elsewhere.
Criterion #1: The Client Type. Internal vs. External Clients, Expectations and The Trust Question
Clients can be broken up into two categories, internal and external. Internal clients consist of people or departments within your organization. External clients consist of people or entities unrelated to your organization, who are purchasing your services or product. As a project leader, you should consider the type of customer when deciding which methodology to use.
Starting with external clients, it is usually the waterfall method that is the easiest to use. Why? It comes down to expectations and trust. First, let’s talk about expectations. As it is common in business dealings, the client may want to know upfront what he is getting. Specifically, he may want to know the deliverables, when these deliverables can be realized (i.e. a timeline) and at what cost (the budget).
These expectations can best be fulfilled by a waterfall approach, where you gather requirements upfront, then define a timeline and budget for the entire project, and then communicate this to the client. Of course, the caveat is that your estimations may be wrong, and your carefully crafted project plan may fall apart, making the customer unhappy.
I also mentioned trust as a factor playing into the methodology question: Let me explain. When working with an external client, you don’t have that kind of trusting relationship that you would have when working for the same organization (being part of the same “family”). At least not initially. But that high level of trust is essential when it comes to winning client projects.
The customer wants to have certainty that you will actually keep your promise and deliver whatever you will be hired for. At the agreed time, in the expected quality and within the set budget. So, the certainty sought by the client is the opposite of what agile can provide. Agile is more like saying “Let’s get started building the first set of features, and then see what to do next”. But that “Let’s get started and then see” approach only will be accepted if the client has a high amount of trust in you.
Trusting you as the partner who is going to act in the best interest of the customer. Trusting that you will (eventually) deliver the desired result — even if it takes several cycles. The thing is, in agile you are not committing to a fixed deadline by when you are going to provide the “product”. Rather, you are working your way through a list of requirements, gradually incorporating them into the final product, while keeping the budget open (meaning you work on a time and materials basis).
So, the client has to have enough trust in you that, when following an agile approach, you are going to give them something that is really of value to them. And this level of trust is usually not present in business relationships among different business partners, especially when it is the first project.
If your client is internal, trust is not that much of an issue. You and the client are part of the same organization, the same team. You more or less share the same values (you may even have been to the same class on company culture). And because you are members of the same group, there’s already a high level of trust present. This is a manifestation of the ‘Unity principle’ that Dr. Robert Cialdini discusses in his fascinating book, Pre-Suasion: A Revolutionary Way To Influence and Persuade (click to show book on Amazon.com).
With a high level of trust already in place, your (internal) client may be more open to starting a project where not all parameters are confirmed upfront. Where the team works their way through the different requirements in an explorer-like manner, gradually gaining a better understanding of the customer’s needs and step-by-step building the product. Basically, because of the trust level, the client feels confident that you’re not going to let them down, but instead provide them with the desired product or solution. Being part of the same organization, an internal client also has more leverage in the form of escalation power should the project not go the way they want. These are all reasons why agile — in general — is easier to implement within the same organization than with external clients.
Criterion #2: Scope Type – Fixed or Flexible Scope?
To illustrate this criterion, take a look at the following (distinctly different) projects:
- Project A: Rollout of standard accounting software
- Project B: Training curriculum development
Project A: Rollout of standard accounting software. You are working for a consulting firm that helps small and medium-sized businesses move to new accounting software. Some of the customers already use some accounting software that they want to replace, while others currently manage their books in Excel or purely on paper.
What can we say about the scope of such a project? Apart from a few questions that need to be answered, the scope (and the features that need to be provided) are more or less clear from the start. Financial accounting is a system with defined processes and rules (in the form of accounting rules) that need to be followed, and accounting is more or less carried out in the same way in every business. You need to be able to handle incoming payments, make payments to suppliers, calculate and pay taxes, create reports and so on. There’s not much discussion needed about features, because the scope (i.e. what the new accounting system should be able to do) is more or less clear and known at the start. This is why you can confidently run this project using a waterfall approach.
Now contrast this with the other project example:
Project B: Training catalog development: You are the Head of Training for an industrial company with 3,000 employees. Currently, your company does not have any systematic process for skill development and training of employees. That’s why you have started a project to create a training catalog with approved courses. This requires you to involve all the functions — sales, marketing, engineering, IT, production, HR and so on — because the catalog should contain course offerings related to all areas.
As you can guess, assembling a training catalog is not a straightforward process. It is impossible to say upfront what the final course catalog should look like – the “end product”. Sure, all areas should be sufficiently represented, but at what level? How many IT courses should be included? How many courses on soft skills to include? And talking about soft skills, what skills specifically should be focused on? In other words: it is not possible to define a definite scope upfront (the desired result can’t be described with high confidence). Rather, the catalog development can be seen as a gradual, evolving and creative process, where you clarify training needs with stakeholders, evaluate course offerings, and — through several iterations — put together a training catalog — a “current version” (that you continuously update based on new requirements). This process is better managed with an agile framework such as Scrum, because you can’t plan out every step from the basis of a clearly defined scope.
Criterion #3: Project Type – Familiar Project or New Territory?
A key component to project management is the type of project. Again, there are two broad categories for projects – familiar and unfamiliar. A familiar project is one that a project team has done many times before and knows all its ins and outs. Here, they are able to estimate the effort and duration of work fairly accurately. The odds of not achieving the project or time running over budget are unlikely. An unfamiliar project is one that is new territory and has not been done before. In this case, the project team hasn’t conducted this type of project before.
If the project is familiar and known well by the team, then the waterfall method may be the easiest to use here. This is because the team can complete the project with ease, since they’ve done it before and know all about timing, pricing, resources, etc. Therefore, they don’t need the client to be involved at every step, and they don’t need to go through trial and error since there are no major “unknowns” (sure there are still some unknowns and risks, as in every project).
If the project is unfamiliar and new territory for the project team, then the agile approach may be the best option. It allows for experimentation via trial and error, learning, frequent changes, and adaptability to the unknown. As we’ve discussed earlier, the waterfall method does not allow for fundamental changes to be made to the project plan, making it fairly inflexible. When dealing with a new project type, there must be room for frequent adjustments and changes, in order for the final product to meet the defined success criteria.
Additionally, in cases with an unfamiliar project, the client should be heavily involved (as in agile), since they may have valuable information to help solve some design questions or provide early feedback on a prototype. For an example, let’s use Elon Musk and his SpaceX endeavors. He is working on creating reusable rockets, with intention of reducing space travel costs. This project is new territory, meaning he and his team have nothing to base their project plan on. Because of this, they have limited details set from the start. In this case, they would likely want to use an approach that resembles agile for this project since they will need to go through a lot of trial and error, iterations, and developmental stages.
Criterion #4: Client Involvement – How Much Does The Client Want To Be Involved?
As a project leader, you should also consider client involvement when deciding which approach to use for a project. Customer involvement varies depending on the type of client and the type of project. If the project is unfamiliar territory, then the client definitely should be involved at every step and the agile approach is the approach to follow, because this methodology is focused on a high degree of customer involvement.
Let’s suppose you are a digital agency that has been hired to build a hotel booking app for a client. The client is very passionate about their business idea and they want to be involved in the app-building process to make sure their app is 100 times better than competitor apps. Additionally, the client can assist the developer team when they are not sure about a design question. This would be an example where you would select an agile approach to accommodate the wish from the client for frequent involvement.
However, if the project type is familiar and the client does not want or need to be involved, then the waterfall approach could be the better option. An example of this could be a doctor who wants to implement a new accounting system in his office. Here, it would not be beneficial for either party to have the doctor heavily involved in this project for a few reasons. Firstly, the project team is familiar with this project and can get it done with a set plan from the beginning. Secondly, the doctor most likely doesn’t know much about developing software, and therefore wouldn’t be able to contribute much. Finally, the doctor has better things to do than micromanage this type of project. All of these qualities point to the waterfall methodology.
I reached out to Mandana Dehghanian, who was a project manager at the International Monetary Fund for over 12 years and mainly dealt with internal clients and familiar projects. After asking her opinion on which methodology to choose for the circumstance described above, she says “Why would I want my client, who specializes in economic development in Africa, advising my team on how to create a website in SharePoint?” I think that this quote sums up the information above well.
Conclusion
With waterfall and agile, you have two general ways of conducting your projects. But how do you know which approach to use for a specific project? Ask yourself the following questions: Is the project team familiar with the subject matter or are you working in new and unfamiliar territory, just like Elon Musk building reusable rockets? Is the scope fixed or do you have some flexibility with regards to what should be implemented? Does the client want or need to be involved in the process? Are you working with an internal or external client? The answers to these questions should guide your decision-making. Keep in mind that you can also follow a mixed approach — also called the hybrid approach. In this case, you do the project planning in waterfall style, but certain phases or activities are carried out in an agile way — usually the implementation. So you have the best of two worlds!
