Editing Analysis paralysis (section)

==Software development==
In [[software development]], analysis paralysis typically manifests itself through the [[waterfall model]] with exceedingly long phases of [[project planning]], [[requirements gathering]], [[software design|program design]], and [[data modeling]], which can create little or no extra value by those steps and risk many revisions.<ref name="BAL">{{cite web|title=Managing Analysis Paralysis|url=http://businessanalystlearnings.com/blog/2014/2/10/managing-analysis-paralysis|website=Business Analyst Learnings|date=10 February 2014 |access-date=15 May 2016}}</ref> When extended over too long of a timeframe, such processes tend to emphasize the organizational (i.e., [[bureaucratic]]) aspect of the software project, while detracting from its functional (value-creating) portion.

Analysis paralysis can occur when there is a lack of experience on the part of workers such as [[systems analyst]]s, [[project manager]]s or [[software developer]]s, and could be due to a rigid and formal [[organizational culture]]. However, according to Ram Charan, indecision in businesses is usually the result of not enough people acting or speaking up about the inefficiencies of the company.<ref>{{Cite journal|last=Charan|first=R.|date=April 2001|title=Conquering a culture of indecision|journal=Harvard Business Review|volume=79|issue=4|pages=74–82, 168|issn=0017-8012|pmid=11299695}}</ref> Analysis paralysis can also arise from extensive experience or expertise, which serves to increase the number of options and considerations that appear at every decision point.

Analysis paralysis is an example of an [[anti-pattern]].<ref name="Sourcemaking">{{cite web|title=Analysis Paralysis|url=https://sourcemaking.com/antipatterns/analysis-paralysis|website=Sourcemaking|access-date=14 May 2016}}</ref> [[Agile software development]] methodologies explicitly seek to prevent analysis paralysis, by promoting an iterative work cycle that emphasizes working products over product [[specification]]s, but requires buy-in from the full project team.  In some instances, Agile software development ends up creating additional confusion in the project in the case where iterative plans are made with no intention on having the team following through.