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

Recap on Phase Gates

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. Phase gates are intended to validate 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. Next phase funding is determined based on business context and organization readiness to move forward.

Expected System Behavior:

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 maximizing “busy-ness” (utilization) of her people.

Unintended Consequences:

Feature filtering:

Phase gates 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 new ideas during requirements gathering phase, but for all of the rest of the times, these same ideas are considered 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 the short window of time many months ago when steering committee decided on scope.

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 the dominance of guesswork in selecting features for future product releases. Guess-work that is trapped in the stale understanding of user needs. No wonder a majority of features in typical products never get used.

Local Optimization:

In waterfall systems movement through phases to the end of the relay race counts as progress. But this perception is false and results in overall portfolio brittleness. During later phase, 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 the next scheduled release. Instead, short-term fixes are implemented. The mindset of getting it right the first time often enforced via governance bodies through exhaustive gating criteria creates a disproportionate impact from risk-event when the requirements or design or code was not right. Unfortunately in a waterfall mindset, such events trigger the need for stricter gating controls, further perpetuating exponential fallout from errors detected in later phases. There is a fundamental misunderstanding of the problem domain, within software system development (big or small, green or brown) attempts to make error-proof phase gates and implement big-brother governance systems will never work. There are known-unkowns and unkown-unkowns. Software products for the most part are explored in the unkown-unkonwns space. Resilience to errors is far more important than error-proof gating systems.

Hidden loopbacks:

When bugs are discovered in the testing phase, typically a bug is reported to developers who then have to apply a fix. While officially the project is in the testing phase, the testers are waiting on developers to apply fixes before they can continue further. This hidden loopback drives the false perception that the downstream phase is taking longer since revisions/corrections to the 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:

Phase gates are innovation killers. Silos and focused functional work straitjackets 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 the 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 through conflict constructively.

Summary:

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

The following process for process’s 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 phase gates. You can iterate on your organizational systems to find your path to success.

Engage us for advise and strategy services to chart your transformation journey.