In previous article, I outlined three fundamental characteristics of waterfall system. Phase-gates are the most distinguishable characteristic of a waterfall organization.

Recap

 Phases are are strictly linear sequence of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential phase is gated to ensure quality of deliverables handed-off between silos. Many decisions are concentrated at gating decision points. The Phase-gate approach provides an illusion of control, delaying feedback on product.

For example:

 Requirements → Design → Implementation → Verification → Maintenance

Gates or gating criterion accompany typical phase-gates. Gates establish GO/NO-GO decision points during the process and are intended to: Assert quality of work during each phase so that errors or mistakes are not propagated to downstream phases. Further funding of next sequence of phases is determined based on business context and organization readiness to move forward.

Expected System Behavior:

Early phases take longer than anticipated and later phases get squeezed. During each phase, work progresses uni-directionally from one phase station to another.

Uni-directional flow of work requires strong emphasis on getting things right the first time. Changes to requirements or design are never ‘welcome’ and always hard-fought.

Product development experiences unpredictable wait-states. Caused due to schedule slippage of predecessor phase and/or due to lack of readiness of subsequent phase.

People get organized in functional silos. Example, Business Analysts silo, Development silo, Testing silo etc. Each silo is lead by its respective manager who is responsible for meeting quality of phase deliverables and responsible for maintaining “busy-ness” of her people.

Unintended Consequences:

Feature filtering:

Phase Gate governance mechanisms concentrate a lot of decisions at gating points. During the early phases of requirements gathering (scoping) many features get filtered out. This is purportedly to limit scope for a release. In other words, business is allowed to be smart to come up with features in a concentrated period of time marked by requirements or product concept phas. All other times their are needs are considered as no good (stupid). This practice leads to selection and elimination of features with out any end user feedback. And also confines understanding of user needs to that time many months ago when steering committee held their “scope” meeting.

As your business context and user needs evolve, so do requirements from a software product. So an idea that may not be appealing at the start may become relevant later. Feature filtering leads to dominance of guess work in selecting features for future product releases. Guess-work that is trapped in stale understanding of user needs. No wonder a majority of features in a typical products never get used.

Local Optimization:

In waterfall systems movement through phases towards the end of the relay race counts as progress. But this perception of false progress at local phase level results in overall portfolio brittleness. During later phases changes in requirements and/or design requested by dependent project teams are aggressively throttled preventing meaningful progress for dependent initiatives.

Degree of influence of dependent teams is inversely proportional to the “progress” made by co-dependent waterfall team. Such systems lead to global sub-optimization at the cost of local optimization.

Root-cause solutions and Resilience:

Late in the development game, technical changes or changes in product requirements are not encouraged. Often deferring these updates to next scheduled release. Instead short-term fixes are implemented. Mindset of getting-it-right the first time often enforced via governance bodies through exhaustive gating criteria creates disproportionate impact from risk-event when the requirements or design or code was not right. Unfortunately in a waterfall mindset such events trigger needs for stricter gating controls, further perpetuating exponential fall out from errors detected in later phases. There is a fundamental misunderstanding of problem domain, within software system development (big or small, green or brown) and attempts to make error proof phase gates and implementing big-brother governance systems will never work. There are known-unkowns and unkown-unkowns. Software products for the most part are exploring in the unkown-unkonwns space. Resilience to errors is far more important than error proof gating systems.

Hidden loopbacks:

When bugs are discovered in testing phase, typically a bug is reported to developers who then have to apply fix. While officially the project is in testing phase, the testers are waiting on developers to apply fix before they can continue further. This hidden loopback drives false perception that downstream phase is taking longer since revisions/corrections to upstream work product is incorporated in downstream phases. 

This perception of “being stuck” in a downstream phase because of issues in upstream work, creates unwanted pressure on downstream folks (testers). Hidden loopbacks not only mask process bottlenecks but also damage relationships between the silos that are pitted against each other.

Innovation Killers:

Phases are innovation killers. Silos and focused functional work straightjackets creativity and rewards bureaucracy. People confined to interaction within their functional community will never learn to work with other functional disciplines. Cross-domain understanding and multi-learning are essential to process and product innovation. We improve in areas where we practice. Your organization needs exercise and practice in working with each other. People will not auto-magically “collaborate”. They need to practice this often, again and again and again (up and down, up and down, painting the fence) until they learn to navigate constructively through conflict.

Summary:

Phases and gates are explicitly and implicitly pervasive in organization mindsets. A serialized cause and effect mental model is comforting but never reflective of how work really happens when you get down to it.

Following process for processes sake is an example of being stupid on purpose. You would be surprised by how many people feel the organizational straight-jackets that you do. Reach out, collaborate, eliminate unnecessary phases and gates. You can iterate on your organizational systems to find your shortest path to project success.

Proceed to part three (Large Batch hands off) or four (Centralized Control).