Discovery is where the team builds genuine understanding of the actual business problem, current state, and success criteria before any design or building begins, and every subsequent phase of the project relies on that foundational understanding being accurate. If Discovery is rushed or skipped, the Design phase produces requirements based on an incomplete or incorrect understanding of the real problem, which then gets built, tested, and potentially deployed, before the misunderstanding surfaces, often not until real users encounter the gap in production. The cost of correcting a misunderstanding grows substantially at each subsequent phase, meaning the time supposedly saved by rushing Discovery is typically far outweighed by the rework required once the gap is eventually discovered, making thorough Discovery one of the highest-leverage investments early in a project.

A formal sign-off at the end of Design exists to create explicit, documented agreement between stakeholders and the project team about exactly what will be built, before the expensive work of actually building it begins, preventing the costly failure mode of completing development only to discover a stakeholder's expectations were different. What sign-off establishes is a clear, agreed-upon baseline of requirements that the project team can confidently build against. What sign-off does NOT establish is that the requirements are permanently frozen and can never change again, since genuine new information sometimes emerges during Build or Test that legitimately requires adjustment. Instead, sign-off means any change after that point becomes a deliberate, visible decision, typically tracked as a formal Change Request, rather than silent scope creep that nobody explicitly agreed to.

A focused clarifying question from an Admin during Build is generally a positive sign rather than evidence of a failure, since it demonstrates the Admin is actively engaging with the requirement carefully enough to notice and flag genuine ambiguity before making an incorrect assumption and building the wrong thing. This kind of active, ongoing BA involvement during Build, answering specific clarifying questions quickly, is precisely the productive level of engagement this phase calls for, distinct from either disappearing entirely until Test or remaining in heavy upfront documentation mode unnecessarily. A true Discovery or Design failure would look more like systematic, large-scale confusion about the fundamental goal of the feature, not an isolated, specific clarifying question about implementation detail.

This should be triaged as a missed requirement or a new request rather than as a bug, since a bug specifically refers to the built solution failing to match what was actually agreed upon and signed off, whereas this scenario describes the solution correctly matching the agreed specification while the stakeholder has since realized they want something different or had not fully considered this scenario when the requirement was originally written. This distinction matters because accurately categorizing issues found during testing is essential for understanding genuine project health; conflating a true implementation bug with a newly emerging requirement makes it impossible to accurately assess whether the build quality is actually poor or whether the project is simply encountering normal scope refinement, which require very different responses and have very different implications for timeline and budget.

A successful Deploy confirms that the solution was technically released into production without immediate critical failure, but it does not yet confirm that the solution genuinely works well under real-world usage conditions, with real production data volumes, real edge cases that test scenarios may not have anticipated, and real user behavior that can differ from how the solution was tested. Hypercare exists specifically as the period where the team closely monitors actual production usage to catch and resolve any issues that only surface once genuine users are interacting with the solution at scale, and to confirm that user adoption and satisfaction with the new solution is genuinely strong, not just technically present. Declaring success purely based on a clean Deploy, before this real-world validation period has run its course, risks missing problems that only become visible once the solution faces actual production conditions.

In a Waterfall project, each of the six lifecycle stages happens once, sequentially, across the entire project timeline, typically with a single, comprehensive Discovery phase producing one large requirements document, followed by one major Design sign-off, then a single extended Build phase, a single Test phase, and a single Deploy followed by Hypercare for the whole project. In an Agile project, these same six conceptual stages still occur, but in compressed, repeating miniature form within each individual sprint, meaning a small amount of discovery, design, building, and testing happens for a small slice of functionality every two weeks or so, with incremental pieces being deployed and monitored continuously throughout the project rather than as one single large event at the very end. The underlying stages are universal across both models; what differs is the SHAPE, whether they occur once at large scale or repeatedly at small scale throughout the project's timeline.