Most of the times the software delays are because of no proper requirements are gathered. Reasons of this could be many like lack of business knowledge of Requirement Gathering Team leaders, lack of experience, inappropriate allocation of time, wrong choice of customer representatives for understanding of business process and requirements and so on. In such cases the level of documentation remains below standards howsoever good may the expertise in documentation be.
Documentation of requirements apparently may look very systematic and structured in first go but once project teams start working for development and testing etc. they start finding out so many gaps and holes in the document showcasing a bumpy road ahead calling for repeated sessions of business understanding from customer and rebuilding of documentation.
Biggest fear in such cases is that if this stage crosses development and testing phase without any hiccups, it definitely does not ensure a healthy situation ahead. Rather it ensures that a volcano or tsunami was in the making during earlier stages is definitely about to erupt or break out soon during rest of the stages. And it could happen anytime.
UAT and implementation stages are most vulnerable stages in such situations where the hidden volcano bursts out when customer business process owner shouts out a flaw in software built to address to their business requirements. Those hidden major gaps unaddressed properly during Requirement Gathering Phase now spell out wounds badly on project.
That is why most of us agree that the most crucial phase of any project is Requirement Gathering Phase. If this phase is not addressed to in a micro level analysis manner, it may cause harm later to project, teams and managements.
Best way would be to vet and validate user requirements twice or even thrice spending a little time extra in beginning rather than asking for a higher amount of critical risks at a later stage.