If you have been following my blogs lately, you will notice a defined theme…a mantra if you will about me which is that I believe in my heart that no project should fail.  With proper communication, expectation setting, risk management and professional project management every project can be managed to successful completion.

Recently, we started debating the statistics about this though.  Within the IT world,  software development seems to fall into 2 camps:  Waterfall and Agile.  There are of course myriad variations of each PMLC/SDLC, but for simplicity let’s focus on these two opposing methodologies.  

A Waterfall project means that teams follow a defined iterative path whereby the scope is defined, the requirements are gathered, the solution is developed, tested and deployed directly in that order.  From a Pareto perspective, a waterfall project is going to spend about 80% of the time on requirements gathering to make sure the full totality of the solution is specified and understood.  The final product is not delivered to the end user until it is fully tested and “accepted” by the client.  However, due to the nature of waterfall, it could be quite some time until the full product is completely ready.  Herein lies one of they key pitfalls to the waterfall approach: 

• If you are building a house, waterfall is a perfect methodology.  With some exceptions, the process of constructing a home is an iterative process.  First, the foundation.  Then lay water, gas and electric lines.  So on and so forth.  Each step must proceed the other.  There are no exceptions.  

• Likewise, if you are building a plane, again, some tasks can be completed in parallel but only after a firm foundation has been put in place.  


In these situations, the process may look like this:  

The notion of waterfall is that each process must complete before the next process can initiate.  Hence the term, “waterfall” to describe it.  

In these examples, again, qualifying with the phrase “for the most part” the requirements are not going to change, so the risk of the time it takes to build both a house and plane with complete quality does not present an undo risk. 

For software, however, far too often the time risk is the critical issue.  Though it may take 24 months to get a software implementation right, often a business doesn’t have 24 months to wait.  Hence, the fallacy of waterfall.  In the realm of software development there are few use cases where it works. There are few instances where a business can know the totality of its business requirements.  Moreover, there a few things a business can do to prevent their business requirements from changing once they are laid down. 

I will never forget my last waterfall project.  We spent 12 months preparing and reviewing and development and testing.  Each step of the way returning to the business to make sure we were on the right path.  Each time being told by the business that we were.  Then, on the day of delivery?  Re-organization.  My business sponsor was ushered out of the company and the new person took one look at our deliverable and declared it unfit for her needs.  The solution was dead on arrival. 


Agile development calls for a complete departure from this Waterfall perspective and accepts all these limitations.  It embraces them, I should say.  If one were to look at the Agile manifesto, they would see the following: 

Agile, in contrast to Waterfall, does not focus on building the full system all at once.  It focuses on identifying features that would provide defined value to the business and could be developed in a rapid fashion – typically evolving over 1-2 iterations called “sprints.”  A key distinction between waterfall and agile though is the presence of the business.  In Waterfall, the business sponsor is typically engaged at the front and tail-end phases of the project lifecycle.  They are there to help convey the requirements and agree to the design proposed by the technical team and typically go “dark”, if you will, until the deliverables has successfully emerged out of QA testing.  This span of time can be quite large.  Agile, assumes that this span of time without business involvement is just too much of a risk to bear.  Rather, it requires that the business remain directly partnered with the application development team to ensure that key the order in which functionality is provided is a result of their prioritization and their concurrence with prototypes that have been demo’d to the business sponsor successfully after every sprint has been completed.  

 A question we are often asked by our clients is which one is the best?  Which one do we recommend?  The answer is not simple.  Sometimes an organizations’ DNA drives us to the answer; sometime it’s a legal/regulatory thing; sometimes it’s a fit for purpose answer.  In either case, typically we will look at a few areas of your organization to guide us.   

• Level of Business Involvement in the Application Development Process 
• Maturity of Business Sponsorship 
• Maturity of the Technical Delivery organization
• Maturity of communication between these teams 
• Maturity of Change Management methodologies 

This series on Waterfall, Agile and Organizational Readiness for Agile will hopefully help you gauge what is right for your organization.  

Stay tuned! 

Best, 

Jonathan P. Goldstein, PMP, MBA
McKinney, Texas