Successfully Managing a Waterfall Project with Individual Work by Agile Teams

As we all know, there are two general approaches or methodologies used for projects: Waterfall and Agile. Before I continue with an explanation of the differences between those two, let me emphasize one major and the biggest difference there is: The PLAN!

Waterfall methodologies are plan driven. Everything is—or should be—known upfront. With a Waterfall project, the scope (what should be done), the time plan/schedule (when each activity will be done), the human resource plan (who should work on what and when), and the costs (how much each activity will cost) should be well defined before the project begins. As we all know, when it comes to IT projects, Waterfall methodology is not suitable. With this approach, a lot of change requests (changes to scope, time, and costs) arise, and there is always a problem with extending those three. This is Waterfall:

Agile methodologies, on the other hand, follow more of a “plan as you go” model. There may be NO strong and fixed plan defined upfront. In fact, just the opposite is true. Plans are made for a short time period (up to one month), and only some parts of the project are planned at all (for that short time period). After that, the customer (or person who is the beneficiary of the project) can see what has been done, is it OK or not, and according to their judgement, can make further decisions on what is going to be done in the next (short) time period. Yes, Agile is better for IT projects. There is no question about that.

This is Agile (Scrum to be more precise, as one of the most known methodologies within Agile project management):

The major differences between Waterfall and Agile methodologies are listed below:

The limitations and advantages of both are shown in next figure:

As usual, it is “Always – BUT!” For the sake of this comparison, we see that is very true. Sometimes (or very often) it is hard to run a project only with Agile. Here are some examples of Agile challenges:

The customer wants to know upfront what will result when the project is finished. In this case, requirements should be defined in the earliest stages of the project, which is likely impossible.

The customer wants to know the budget. Funding must be prepared upfront, and to get that funding, one must know the scope!

The customer wants to know the deadline (i.e. when the project will be finished).

These challenges are also known as triple constraint, or the “iron triangle,” as shown below:

With only Agile or Waterfall to choose from, what is a project manager to do? The answer is a hybrid model, also known as “Water-Agile-Fall.” Here is a picture, which explains this type of methodology:

Basically, it is Agile inside of Waterfall. How does it work? Remember, Waterfall is outside and Agile is inside.

Let’s suppose that we have a fixed scope, fixed time, and fixed price IT project. Contracts should be signed according to statement of work, WBS, and schedule. All requirements are collected and estimations are done at the very beginning. After that, when the execution of the project has begun (i.e. the design and development phase), the project functions with Agile methodology. We can organize Sprints (Scrum), Kanban Board (Kanban), or something else. The greatest benefit of this hybrid approach is that we can show and deliver as we go, and the customer will be aware of what is he is really getting. This is a much better scenario than one “big bang” delivery. In a classic Waterfall approach, customers get everything at once at the end of the project, and there is a 50/50 chance of satisfaction with the solution. More realistically, the 50% chance that our customer will not be satisfied is actually a 99% chance. Why? Because he hasn’t seen anything until the project’s end. By then, it is too late to change things.

With a hybrid model, the customer has multiple opportunities to see and react during development in short time periods. He can change his mind or add something new. With this approach, it is much easier to reach agreement that something is out-of-scope because it has already been defined. We have the option to get more funding and/or time. Best of all, we have a good chance of there being a successful trade-off (i.e. the customer will give up of some previous defined and desired functionalities in favor of some new ones, which many have not been considered or defined in the original plan).

In summary, my recommendations are as follows:

Use Agile whenever you can. This is the best approach!

If you can’t go Agile all the way, do not go Waterfall as the only other option. Instead, go with a hybrid “Water-Agile-Fall” method. You’ll be able to take the best from both methodologies, and with frequent delivery, you will have your customer on your side from the very beginning, throughout, and until the end of the project!

Nenad Trajkovski was born in Zagreb in 1963. year. After completion of Faculty of Electrical Engineering, Nenad has started on the development and implementation of enterprise systems (ERP) in companies of various areas (banks, card houses, production companies, auto industry, wholesale businesses, oil companies, and others). He has extensive experience in working with business processes, people and knowledge in information technology and financial accounting activities.

Currently, Nenad works as a consultant for the implementation of business systems, and as Project Manager. He is trainer for Project Management and Risk Management in Microsoft Innovation Center in Varaždin. At WinDays08 conference he has been declared as the best speaker, and his session as the best one. He was among TOP 10 speakers in the Microsoft Sinergija 2009 and at the Microsoft Vzija 2009. Shared first place as the best lecturer at KulenDays 2009 and the PMI Forum 2009 in Zagreb. Regular speaker at the Microsoft Community. On WinDays10 conference Nenad was among the top three speakers; at the conference Microsoft Vision 9 in Skopje between the top 5 speakers as well as on Microsoft Synergy 11 which was held in Belgrade. Certified Accountant, PMP (Project Manager Professional), PMI – RMP (Risk Manager Professional), MCP (Microsoft Certified Professional), MCTS – Microsoft Project 2010 (Microsoft Certified Technical Professional). and MCT (Microsoft Certified Trainer).

8 Comments

Isn’t this just reality? In my 20+ years of managing IT projects, I’ve never, ever, not even one time had a waterfall project (purely finish-to-start task dependencies). There has never been the luxury of sequencing work that way. The idea would get me laughed out of the office. Maybe the odd bit here or there for infrastructure builds, or solicitation/purchasing due to internal rules, but definitely not the project as a whole.

Everything has to be overlapped and exceptionally iterative or cyclical out of necessity whether it’s called Agile, RAD, RUP, Progressive Elaboration, or any of the other iterative methods. I’ve never met anyone who ran a waterfall IT project since the dawn of e-commerce. Not since my dad retired from Pascal, Cobol, & Fortran programming in the mid-1980s anyway.

PMI has never taught or published direction to run a waterfall (Finish-to-Start) project. Quite the opposite. The scheduling standard expressly teaches to find overlaps, efficiencies, and ways to reduce the end to end duration. Anybody out there who is running in waterfall-only mode must have a really good reason (that I’d love to hear).

Comment by Sonya Calef on 08/28/2018 at 9:47 am

Excellent topic!

Comment by Hieu Ho Trung on 08/28/2018 at 10:08 am

Excellent topic, thanks. I agree with Sonya on IT projects never really being waterfall. Like my guru says: “There is no waterfall, neither agile. Everything is hybrid!” But, in a structured, project-managed organisation trying to balance resources usage between projects, maintenance and other activities, PMs need to plan resource usage to both “reserve them” and represent planned costs. For “waterfall-like” parts of projects (initiation, definition, training, transfer to production, etc.) I encourage my clients to plan tasks in the old fashion way, with dates and assignations. In the Agile parts (mainly design and development) we plan one task per iteration, assigning all Agile teams resources to this task, for an agreed percentage of their time. That way, we efficiently represent resource usage but do not interfere with the Agile teams’ responsibility of deciding which work is done in each iteration. For those “tasks”, we evaluate work advancement by using a “realized points over planned points” ratio. These figures are usually easy to get from an Agile tool as Jira or TFS. That way we can easily get global KPIs. My ten cents.

Comment by Jean-François Beaulieu on 08/28/2018 at 11:20 am

I really dislike responding negatively to an article, but there are so many things wrong with how a waterfall project is stereo typed in this article. Having managed projects for dozens of years, waterfall projects can be, and are, very flexible. Functionality/value can be delivered iteratively or as a big bang, depending on what the customer wants and what makes sense. As for customer involvement, waterfall projects are not developed in a cave with a “customer keep out” sign over the door. The reality is that customer involvement needs to be what it needs to be, regardless of delivery methodology. I currently live in a mixed methodology environment and Agile/Scrum is not always the best approach. Very small isolated software development projects tend to realize more of the Agile benefits while larger, complex projects and infrastructure/process projects tend to benefit more from a waterfall methodology. Bottom line, do what makes sense for the project, and as prior responses have stated, this is usually a hybrid approach. Locking into one methodology just “because” is definitely not the right approach.

Excellent topic! Often I have had to work with teams implementing a hybrid WaterFall/Agile methodology. There are many instances where you need to know upfront the plan, i.e. infrastructure builds, upgrades to allow applications that can take a more agile approach. Of course through planning you can have infrastructure as a services (IAAS) that is more agile than waterfall. This was an excellently written article. Thank you greatly!

Comment by Glenda Collins on 08/28/2018 at 4:45 pm

Everything is—or should be—known upfront. With a Waterfall project, the scope (what should be done), the time plan/schedule (when each activity will be done), the human resource plan (who should work on what and when), and the costs (how much each activity will cost) should be well defined before the project begins.

I will be generous and say this is a poorly drafted explanation rather than a misunderstanding. A waterfall model commonly starts with analysis / requirements gathering. No PM could ever schedule the detail design without having the requirements, nor schedule the development without the detail design, nor schedule the deployment without the development (mostly) complete etc. etc.

Comment by Phil Planner on 08/29/2018 at 6:45 am

Daryl, my article is not meant to be like: “Waterfall is all wrong”. but in my experience almost always in my projects I have to know scope upfront. And this is the hardest thing. Because (I’m talking about IT SW projects), customer knows what he wants AFTER he gets what he said he wants (in Specification). And then, we are facing the problem. If you didn’t get what you wanted who will pay for what we have delivered, and who will pay for the change.

Comment by Nenad Trajkovski on 08/29/2018 at 7:50 am

Dear Nenad, Thank you so much for this great article. I totally agree with your hybrid approach, especially that we adapted it recently in one of our software development projects. I was struggling with how to explain this concept to our top level management but you put it in a very clear and nice way. In project management as I learned there is no clear wrong or right but there is bad, good, and the best approach. So I do adapt the approach that serves my project the best whether it is agile, waterfall or as you said Water-Agile-Fall.

Please complete this equation so we know you’re not a robot. * − two = 3

Sign me up for the newsletter

By submitting a comment you grant MPUG a perpetual license to reproduce your words and name/web site in attribution. Inappropriate and irrelevant comments will be removed at an admin’s discretion. Your email is used for verification purposes only, it will never be shared.

RELATED CONTENT

MPUG HIGH FIVE VIDEO TIP

Track Down Resource Scheduling Errors in MS Project

TRY MPUG ONLINE TRAINING FOR FREE

Try the best MS Project and Project Management training free for a week with no obligations.