Just like using the right people or tool for the job, using the best approach when delivering a project is key; and no single approach is right for everything. This article will discuss some of the mechanics of a more traditional approach, commonly called waterfall, along with some of the mechanics of an Agile approach and when to use each one. We will also look at which constraints are fixed versus variable in each type of approach and the effects they have on our ability to manage the changes that inevitably arise.
What is Waterfall Project Management
Let’s start with what we mean by a Waterfall approach. Essentially, it’s the most traditional way of running projects – the one you probably think of when you hear the term Project Management. In 1970, Winston Royce wrote an article entitled, “Managing the Development of Large Software Systems”, which was quickly adopted by the federal government and has been used by project managers worldwide ever since. The article discussed an approach where a project was performed in phases, with each phase taking on the final deliverables of the prior phase. It was coined “waterfall” because that’s what the shape of the project looks like (see diagram below). The problem, however, is that this approach assumes perfection at the end of each phase. When practiced in real life, it typically requires rework, formal change control, etc. To Royce’s credit, he actually calls out how risky this approach to projects is in his article.
Looks like a waterfall… get it?
What is Agile Project Management?
Fast forward to 2001, 17 self-professed “organizational anarchists” and software developers wrote something called the Agile Manifesto, which codified their beliefs on how to better develop and deliver software. Since that time, Agility – and the quest for it – has become common within organizations. In an Agile project, instead of separating out each phase, a small piece of work across all of the phases is performed within a short span of time called a Sprint. However, this approach is not right for every project. Let’s take a look at when it’s useful and when it isn’t.
Understanding Project Complexity
Ralph Stacey designed the Stacey Complexity Model to show how projects can contain different amounts of complexity. The Y axis (the vertical line below) shows the rate of change when it comes to what we’re creating or building, essentially the speed at which the requirements of a project change. The X axis (the horizontal line below) shows the rate at which the how will change. This can include not only complexity and uncertainty in technology needs, but also other components that make carrying out the project more difficult (changing stakeholders and/or team members, complexity of communication caused by distance between team members, etc.) For Simple and even Complicated projects (work we’ve done several times before and have a pretty good handle on – or ones where either the what or the how is in flux), a traditional or waterfall approach works best. However, when it comes to projects that are Complex, where the what we’re creating and how it’s going to be created changes often, an Agile approach is better. Let’s talk about why.
How Waterfall Projects Control Change
One of the main differences between a traditional and Agile approach is how each type of project looks at the elements of a project and how each manages change. A more traditional approach has us define the entire scope and requirements of the project upfront, which will drive how long we think the project will take and how much we think it will cost (see diagram below). Unfortunately, once the scope is defined and before the project starts, many Project Managers then attempt to lock down the schedule and cost and save it as a “baseline” creating issues for themselves and the project later on. For the meantime, however, we will assume schedule and cost are variable. Project teams then attempt to control changes in the project by instituting a rigid change control process. We also run the risk of schedule delays and cost overruns.
The problem is that we know the least about our project at the start and predicting (and then trying to control) the future is impossible to do. Further, if and when we show deliverables to our customers during the course of the project, they will invariably give feedback and, often, will want to make changes, many of which are beneficial to the project. Unfortunately, incorporating these changes, particularly when a project is well underway, is extremely difficult to incorporate and involves rework.
How Agile Projects Control Change
With an Agile approach, we are able to rapidly capture and incorporate change in a project. This is because, with Agile project management, we fix the schedule and cost upfront (for example, by having set deadlines at, say, the end of every two weeks in our “sprint”) where we have to show a “potentially shippable” product. Our costs are fixed because we know how much time the team will be working on this project and can easily calculate the cost of people’s time. In an Agile project, we also structure requirements so that we’re delivering the most important and impactful items first, not just the tasks that happen sequentially. If we have to drop less important scope later on in the project, then we do, doing away with the persistent problem that Project Managers face in a traditional project, namely that of “scope creep”.
Other Benefits of an Agile Approach
Each year, VersionOne creates a “State of Agile” report that shows how industries and practitioners are using Agile concepts. I really like one of the diagrams that they produced in a prior year (see diagram below – The dotted line shows a more traditional approach. The solid line shows an Agile approach.) that sums up some key benefits of Agile project management. Below is a quick summary of the differences between using a traditional versus an Agile approach.
- Visibility: In a traditional approach, once a project team kicks off a project, the team will disappear, reappearing closer to the end of the project to show customers the final product. In an Agile approach, teams are showing customers products every 1-4 weeks, getting feedback, and incorporating that feedback into the product or service. There is much more overall visibility from a customer’s perspective with an Agile approach.
- Adaptability: As discussed above, a traditional approach assumes perfection up front, and changes become difficult to incorporate once the project is underway. An Agile approach allows teams to more easily review and incorporate changes into the project.
- Business Value: By creating something tangible at the end of a few weeks and making sure the most important and impactful products and services are delivered first, we create value for customers more quickly at the start of a project, rather than requiring our customers to wait until later on in the project before they receive something tangible.
- Risk: In a traditional project, risk is inherent (and risks are actively managed by a project team) throughout a project. Whereas, in an Agile project, teams not only deliver the highest impact items first, but also those items with the most complexity and/or risk first, so that those items are reviewed by the customers and removed from the project upfront.
To sum up, the Waterfall approach is best with simple and somewhat complicated projects. However, when we’re faced with situations where there’s a lot of uncertainty or change around what we’re delivering (with, for example, our requirements) or how we’re actually delivering the project itself (uncertainty or change around technology, working with large or distributed teams, etc.) and the project is complex, an Agile approach is best. Agile project management also allows us to better manage changes, provide value to clients and stakeholders more quickly, decrease risks at the outset of a project, and provide more visibility throughout the project.