Hybrid Project Management - How 'Hybrid' Came to Be

Hybrid Project Management - How 'Hybrid' Came to Be
Page content

The hybrid approach to managing a project is not a strict methodology.  It combines elements of the waterfall and agile methodologies in a unique way on each project, acknowledging that both have benefits.  This article asserts this point by presenting a short review how these methodologies came to be.  Even today, both approaches bring something to the table on nearly every project, and thus nearly every project can be considered to be a hybrid project. This is the first part of a series of four articles on “Hybrid Project Management”, where we explore the evolution and logic behind hybrid project management, and how you can optimize performance on your hybrid project by selecting the ideal waterfall and agile techniques.  This article, Part 1 in the series, looks at “Hybrid Project Management:  How ‘Hybrid’ Came to Be”, including how project management methodologies have evolved from waterfall to agile…to a hybrid of the two.  Part 2, “The Spectrum from Waterfall to Agile:  Three Hybrid Projects”, looks at some different types of projects and what makes them uniquely challenging to manage.  Part 3 focuses on “Five Factors to Optimize Your Hybrid Project”, enabling you to identify the key characteristics that will inform your PM methodology approach.  Finally, Part 4, “Leverage Waterfall and Agile Techniques on Your Hybrid Project,” dives into how to choose the best of techniques to leverage on your specific project.   The origins of the waterfall method date back to the 1960’s, when efforts were being undertaken as to how to manage large, complex, technologically based projects.  These efforts culminated in 1970 in a noted paper, “Managing the development of large software systems,” written by Winston W. Royce.  Royce began his career as an aerospace engineer, but soon found himself working on large, complex software systems and endeavored to develop new methodologies for improving the management of such projects.  His paper is generally credited with defining the “waterfall” model of the software process.  It surely incorporated knowledge and experience from the more established aerospace engineering field into the nascent software development field. This original paper on the waterfall method notably incorporated prototyping as an essential.  While a thorough approach was required, it was acknowledged that there is inherent risk in a single-pass sequential approach.  Thus, as waterfall approaches matured, the incorporated an iterative and incremental component, where every next step links back to the step before with feedback loops from testing back to analysis and design.  It seemed that it was already acknowledged that the challenge of developing software could not be solved by specifying everything up front. Many modified waterfall models were introduced over time to fix problems with the “pure” waterfall model.  These included “modified waterfalls, or Rapid Development models, devised by Steve McConnell; the “sashimi model,” which incorporated waterfall with overlapping phases; waterfall models with subprojects;  and waterfall with the application of risk reduction techniques. Eventually, this was all boiled down to four factors which influenced development:  processes and tools, documentation, working with the customer, and approach to planning and change. These four factors are beautifully described in the Agile Manifesto, published in 2001, which clearly distinguishes preferences for handling them, without specifying exactly how:

  1. Individuals and interactions over processes and tools – Processes and tools are not pronounced useless, but interacting as a team to solve problems is more preferred.
  2. Working software over comprehensive documentation – Documentation also is not useless, but functioning results are more preferred.
  3. Customer collaboration over contract negotiation – A collaborative teaming approach is preferred, acknowledging that change will be inevitable. 
  4. Responding to change over following a plan – While developing a plan is useful, it is critical to also be flexible.

Thus, agile itself is inherently a ‘hybrid’ approach.  It does not prescribe what to do, but instead nudges in a direction and leaves it up to developers to decide. How can you leverage the key precepts of both waterfall and agile on your project?

This post is part of the series: Hybrid Project Management

This series of four articles looks at different facets of Hybrid Project Management. These aspects include how “hybrid” came to be, spectrum from waterfall to agile, five factors to optimize your hybrid project, and leverage on both waterfall and agile techniques. Hybrid Project Management - How ‘Hybrid’ Came to Be The Spectrum from Waterfall to Agile: Three Hybrid Projects Five Factors to Optimize Your Hybrid Project Leverage Both Waterfall and Agile Techniques on Your Hybrid Project  Photo courtesy of pixabay.com