Problems caused by skipping analysis stage of SDLC

There's an old saying that if you don't know where you're going, any road will do. The analysis stage of the software development life cycle (SDLC) is intended to tell the project where it is going so that it can take an appropriate road which indeed leads to the project's delivering desired value.

If the analysis is skipped, the project is unlikely to get where it needs to be, and certainly not in the most expedient way. Actually, the analysis stage is not skipped, but rather "skipping" means it's done in an inadequately-informed informal non-explicit manner based largely on presumptions which probably are going to be illusory and misleading.

However, the answer is more complicated. While it's true that skipping the analysis undoubtedly produces problems, it's not true that merely doing something you call "analysis" prevents those problems. The analysis has to be done appropriately and must be followed by adequate design and implementation. Too often none of the above occurs.

Analysis should be discovering what I call the REAL business requirements deliverable whats that provide value when satisfied by the product/system how. Very often, though, what is called "analysis" actually is design, which means that the project has skipped to the how without adequately identifying the whats the how must accomplish in order to provide value.

Techniques used for documenting the requirements, which are the output of analysis, don't change the likelihood that things such as use cases and user stories, which often are believed to be the "requirements," often actually are forms of design.

Analysis is a function which needs to precede design. Neither has to be considered an explicit stage. For instance, those following agile methodologies probably wouldn't refer to analysis and design as stages; but effective development depends on doing an applicable amount of analysis and design in order to define what the code should be.