Is the Waterfall Approach Outdated?

11-20-20Andy Skotnicki

by Andy Skotnicki

Rushing to find a better way to greater efficiency isn’t necessarily a bad thing, if done for the right reasons. The classic Waterfall approach (often referred to as the V-model in the SE community) represents an incremental progression of solution maturity across time and across the “system” lifecycle. So why do many in the Systems Engineering community think it’s old school, and possibly even outdated? Probably because they tend to view it too narrowly and with a checklist-like sequential progression mentality rather than as a general guide.

How Systems Engineering is taught during hours or even days-long training is partly to blame. This training tends to emphasize management processes vice actual architecting and engineering fundamentals, so trainers tend to oversimplify in order to standardize within an allotted time. If all things are equal and don’t often change, then standardization is a good thing. Unfortunately, engineering doesn’t fit nicely into manager (and even customer) -preferred “swim lanes.” Real life situations don’t typically abide by standards, and these situations don’t follow a clean path. In reality, Systems Engineering is highly iterative and evolving throughout the system lifecycle, so multiple approaches may be needed to compensate.

The Waterfall approach is valuable as a general template and is still appropriate for most applications when properly tailored, but there are other approaches/models that may be better suited depending on the program’s risk posture. It’s all about solution-based risk identification and mitigation for Systems Engineers. Less risk requires less formality (including documentation), less or more tailoring (depending on what’s considered baseline in an organization), and less unique skillsets. Progress is more predictable in this case. However, when the risk level increases (with a simultaneous risk tolerance decrease), everything becomes, or should become, more custom. When the right customization doesn’t happen, the approach is blamed as not responsive, or takes too long, or is too burdensome, etc. How an approach/model is applied within an organization, across a program, and even across specific projects within a program matters. For example, the Enterprise can be viewed as a never-ending cascade of V-models, forming what’s referred to as a W-model that continues as long as the organization continues. Some projects within the Enterprise may also use a V-model or some variant, like an N-model (if reverse engineering is needed first), or a Z-model (if applying MBSE in “agile” friendly layers). A subordinate project may use a risk-centric spiral model since a technology or its application may be immature, and yet another project may use an approach more closely aligned with DevOps or other software development needs. It’s not unheard of for some organizations to employ multiple models simultaneously.

So is the Waterfall approach outdated? No, of course not, but we need to understand how and when to tailor and apply the Waterfall approach generically, or its variants specifically (including the more modern V-model representation), to achieve the desired results. Arena Technologies has the theoretical understanding coupled with decades of applicable experience in engineering leadership to align programs and individual projects for success, vice just hoping for it.

Leave a Reply

Your email address will not be published. Required fields are marked *