Anyone who has ever worked in a project — as a project manager or in the wider project team — will tell you that completing on time, in budget and within scope is far easier said than done. A multitude of external or systemic factors can hinder a project’s progress, and the result of these events on the project’s success can be hugely significant. Choosing the right project management methodology is a key part of ensuring that your project runs smoothly.
In this post, we look at a question that is dominating the project management debate: Is agile the solution to creating faster projects with better results, or just another project management buzzword? To find out, we aim to answer the following questions:
Why are methodologies important?
What is the waterfall methodology?
What is agile project management?
How can I decide which methodology to implement?
Why are Methodologies Important?
The project management methodology you choose connects a wider business strategy to the people who turn its ideas into realities, providing the framework necessary to make things happen.
For this reason, choosing the most suitable methodology requires a clear understanding on both sides of the business about the needs of a company, which is essential to achieving positive outcomes through focused project work. It is important for business leaders to have a solid grasp of development processes, while it is equally necessary for non-customer-facing teams to understand the requirements of corporate stakeholders and know what they need to do to meet them.
Selecting an appropriate project management strategy, twinned with effective communication at all levels of the organization, can help companies achieve their goals. The choice between classic and agile methodologies defines the way in which project managers approach their projects, which in turn has a significant impact on results. It is thus important to understand the strengths and drawbacks of each approach to ensure that the approach you choose helps you execute your project efficiently.
About Waterfall (Traditional PM)
The Waterfall Methodology is a relatively simple philosophy: define what needs to be done, then do it. The process of deciding on a project’s to-dos depends on the three factors: time, cost and scope, the corners of the so-called project management triangle.
The balance of these three factors will greatly influence how the project’s deliverables finally look. During the project initiation stage (see below), a consensus on the correct balance should be established, then finalized in the planning stage.
Now that’s important! Waterfall requires the exact requirements and specifications of the finished product to be documented from an early stage.
On the positive side, this makes it crystal clear to everyone in the project team what is expected and serves as a guideline at each development phase. On the other hand, specification writing is a hugely time-consuming process that may affect the project timeline: the specification itself has no value to customers and may be the subject of lengthy debate.
Waterfall is generally split into five distinct phases:
Initiation. At this stage, the project is given the “green light” by its sponsor and the initial scope of the project is defined.
Planning. The project scope presented at the initiation stage is greatly elaborated upon with specifications and other technical details. Formal guidelines for cost and time are also set at this point.
Execution. During this stage, the work of the project is carried out according to the project plan.
Monitoring. The work performed during the execution stage is evaluated and steps to correct any deviations from the project plan are implemented.
Closure. The final stage includes customer sign-off and the archiving of project documentation. It may also include a “lessons learned” workshop that is designed to help teams perform better for future projects.
Each of these phases has a checklist that must be completed before the next stage can be started, a process known as the Waterfall approach.
About Agile
“Going agile” is an important buzzword in modern business: a holy grail for development teams that is often spoken of, but less-often properly understood.
In its truest form, agile refers to software development, and elements of the methodology has been in widespread use since the 1950s, leading to the publication of The Manifesto for Agile Software Development in 2001. The success of agile in the software development sphere has led to its implementation in many other types of industries, such as mechanical and electronic development.
The exodus away from traditional methods and towards the agile approach to project management is in part due to the systemic limitations of classic project management itself. In a fast-paced and competitive business environment, there is a clear need to manage projects in a less-rigid manner that facilitates more freedom in work. Rather than focusing on documentation and processes to guide development, agile projects are flexible, consisting of nonlinear interactions that respond to specific issues important to customers.
The key values of agile were outlined in the manifesto as follows:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
This approach should ensure a better distribution of resources throughout the project team. By investing less time in creating specifications, plans and project documentation, efforts are invested instead into the development of the product itself after each new release. However, to think of agile processes as less disciplined than classic project structures is a misconception: without full commitment to these principles, an agile project will fail.
Agile project management is iterative. In a product development project, deliverables would be created through the development and release of new versions at regular intervals during the project. As the project progresses, these versions come closer to the initial project goal, but simultaneously incorporate input generated during the development. The periods between releases are called sprints, which usually last for two to four weeks. After each sprint, another version is released. This approach also allows agile teams to work closer together with the customers that they are developing for, who in turn can be more heavily involved in the development process.
However, agile methodology can be applied to different types of teams too, such as marketing. For a brand awareness campaign, it could work as follows: rather than selecting a target audience in the planning stage and sticking to it, an iterative approach — testing and analysing sample materials on smaller audiences — could be used to identify the most suitable recipient group. You could apply the methodology further to test out different styles of messaging and content. In this context, working according to agile principles may lead to better results for the campaign, as the flexibility in the agile approach allows the project team to react faster to feedback.
Positives and Negatives
The best way to visualize the difference between the waterfall methodology and agile project management is to consider yourself as a customer in a restaurant. The development team would be the kitchen staff (and the head chef would be the project manager) and the corporate management would be the restaurant owner.
Everyone in this scenario has relatively clear goals. The restaurant owner wants good customer experience and for the restaurant to sell more meals. The kitchen staff want to do their jobs in the most efficient way possible, and you would like something tasty to eat.
With Waterfall you would browse the menu and order the dish you wanted. The head chef would then write down which ingredients were necessary, what needed to be cooked and for how long, and who was responsible for chopping, frying and washing up. The kitchen staff would then follow the plan of the head chef to the letter, resulting in your food being delivered to you some time later.
In agile project management, you would go into the kitchen yourself and become heavily involved in the preparation of your own food. The kitchen staff would present you the “latest” version of your food after each step in the recipe, allowing you to add more salt or pepper, cook your steak a little more, or add ketchup instead of mayonnaise to your fries. Eventually, you’d end up with a meal that you wanted, even if it wasn’t exactly the same as what you originally ordered.
In this context, you can clearly see that there are positive and negatives to each approach. The “traditional” approach does not leave much room for interpretation for the kitchen staff, which in turn creates standardized food that does a job, but doesn’t necessarily make the chefs very happy. Likewise, for extremely complicated dishes, the process of writing down what needed to be done would take an incredibly long time, which would in turn cause the customer (and in turn the restaurant owner) to be unhappy.
Similarly, the “agile” approach has a number of logical pitfalls. Becoming too heavily involved in development can cause major problems, especially in the latter stages of a project. Too much tinkering could “spoil the broth”, take even more time than simply writing down the instructions and, if left unmanaged, could even lead to conflicts between the customer and the chefs.
In a restaurant, the selected approach would depend on what you wanted to eat (or in a business context, what you want to develop). For a sandwich, you probably wouldn’t want or need to be too heavily involved in how the bread was buttered, whereas for a filet steak, you might prefer a more “hands-on” role. As such, the “correct” project management methodology depends on what your project should achieve.
How to choose
Let’s be clear here: going agile won’t be the right approach for every project. While agile sounds like a more intuitively-developed approach to project management, is not always the best way to guide a project from start to finish, and sticking to a more conservative model may be preferable. The question of which of these highly divergent approaches is best-suited to your company must be decided on a project-by-project basis. In this section, we look at the factors you should consider when deciding which methodology to implement.
Overview
There is no “one-size-fits-all” approach to choosing a project management methodology. Project managers should first understand the nature of their projects and then select an approach depending on how it fits the individual project’s characteristics. This at-a-glance table can help you get familiar with the basic tenets of both approaches.
Project Complexity
You’ll probably have a good idea in advance about the complexity of your next project: what needs to be done, who needs to be involved and what might change between the project start and end. For a simple homepage redesign, you might only be looking at involving a few team members from different departments, all the time working to a clear plan. On the other hand, the development of a new flagship product for your organization could plausibly require thousands of hours of work from departments all across the company, and the end result could differ substantially from your initial ideation.
If the requirements of your project are unlikely to change substantially while work is still being done, classic project management will usually be sufficient to guide the process from start to finish, as fewer iterations are required and a single monitoring phase may be enough. Especially if the project tasks are less dependent on each other to complete, there is a smaller likelihood of bottlenecks causing delays.
However, if you will need to experiment, alter and adapt your project to rapidly-changing requirements, an agile approach is definitely worth considering. The constant iteration loops and the ability of individuals to make important decisions quickly means that bottlenecks and “blocker tasks” can be minimized before the project goes off track.
Customer Involvement
Many companies develop products for a single customer or for a small group of customers in which a “lead customer” is defined. In these cases, your development strategy will depend heavily on input from the customer, which is why an agile strategy could help keep progress aligned with customer expectations through regular controls and multiple iterations.
The less-flexible approach of traditional project management means that changes to the scope are harder to implement.
Firstly, because the documentation and project plans are more extensive and secondly, because the control phases are less frequent and more work takes place between them. This approach is more suitable in many scenarios, especially when the scope of the project does not depend heavily on customer feedback. This is not to say that classic project management does not provide the opportunity for customer feedback to be implemented, but this generally has a negligible impact on the overall project outcome.
Team Character
The project management methodology you choose will have a huge impact on the way your team works. The question is: will it help or hinder your project if team members can make decisions that could affect the outcome of the project? Will the necessity to align with the entire team provide the correct level of checks and balances to ensure the project stays on course, or will it slow work down and cause delays? The answers to these questions should give you an idea of which methodology to implement.
Waterfall uses a “top-down” approach. Tasks are delegated by the project manager, who also ensures that processes are being followed correctly and according to set written protocols. As long as deviations from the plan are not foreseen (for instance because of changing customer requirements) a more straightforward approach to completing tasks will invariably lead to them being completed faster and closer to specification. However, if project members notice problems, this bureaucracy may stop them from reacting quickly.
On the other hand, agile projects are generally more democratic due to the “people over processes” mantra. People working in the project are able to see quickly whether or not the outcome will be as imagined, and also predict if it’s the right or wrong approach early. They are also empowered to make decisions if they feel that a different way to tackle the problem may be fruitful. If cross-departmental collaboration in your company is good and your teams can reach positive outcomes through collaboration and without rigid processes, agile processes provide a greater scope for them to shine.
The Right Tool for the Job
In short, the choice between classic and agile approaches is a question of preference: from the decision makers at the company, to the customers, to the project managers, onto the project teams themselves. By properly evaluating your next project and its goals, desired outcomes and potential risk, you can select the correct methodology on a case-by-case basis.
Going Agile? MeisterTask is the perfect tool to help you implement agile processes in your organization. Its Kanban-style boards transform your workflows into easy-to-follow visual processes — customizable to suit your organization’s every need.
