1. Mistakenly compare software development to civil engineering. A common analogy is to compare software models to architectural diagrams for a bridge or building.  Unfortunately the analogy isn’t an accurate one: software is more malleable than concrete making it easier and much less expensive to change your mind part way through the effort; The material (app servers, operating systems, …) used to build software isn’t as well understood as the material to build bridges (steel, concrete, …) making it much more difficult to accurately plan up front; Incremental delivery often doesn’t make much sense when you’re building a bridge, so what if the foundation has been set but the rest of the bridge isn’t in place, although incremental delivery of software is clearly possible and as I argue above the norm.  Much better analogies are comparing software developers with chefs or comparing software development with putting on a play (as described in the wonderful book Artful Making).
2. Get motivated to do so by the business.  Your business stakeholders often demand "accurate" estimates and schedules to be developed early in the lifecycle so that they can determine whether they want to fund the project.  This motivates IT people to model in detail up front to support the creation of those detailed project plans, plans which often prove to be wildly inaccurate in practice.  This inaccuracy is the result of our stakeholders being unable to tell us what they actually want, this is human nature, so as a result the quality of our estimates are only as good as the quality of the information the they're based upon.  We need to educate the business on the inherent challenges associated with fixed price projects and provide them with better strategies for funding agile projects.
3. Think comprehensive requirements documentation means something.  There is a common misconception among project stakeholders that you can fully specify a system before constructing it.  Yes, you can in fact do so, but as you see in Examining the "Big Requirements Up Front (BRUF)" Approach this leads to incredible amounts of wastage even if you end up "successfully" delivering software.  In other instances, development teams often misunderstand, or outright ignore, parts or all of the requirements specification anyway.
4. Don't know any better.  Many organizations have spent the last thirty years putting a well-defined, non-agile, and very serial process in place that encourages BMUF.  The U.S. Federal Government is a classic example of such an organization, often requiring extensive requirements documents to be created before allowing any other form of development to occur.  Yet, as this site shows, you do in fact have other options.
5. Are overly specialized.  When you staff your project with specialists, they'll perform their specialist tasks very well whether it's appropriate or not.  When you have modeling specialists on the project they'll do a lot of modeling, and likely write a lot of documentation, because that's what they're good at.  The end result is that you'll get far more documentation than you actually need -- you pay for it, you get it.  What you really want are generalizing specialists who have the skills and abilities to do just enough modeling, coding, and so on.
6. Believe programmers don't have the skills to model themselves.  This is a self-fulfilling prophecy.  If you hire overly specialized people, then set up an environment where one group of specialists hands off work products (e.g models) to other groups of specialists, then you pretty much guarantee that they won't learn a wider range of skills.
7. They got sidetracked by traditional data professionals.  Unfortunately many within the data community believe that you require a serial approach to design, particularly when it comes to databases.  This belief is the result of either not understanding evolutionary development or some misguided need to identify the "one truth above all else".  Evolutionary database design techniques such as agile data modeling, database refactoring, and database regression testing work incredibly well in practice.   

I suspect that the best thing that can be said about BMUF approaches is that it provides a context which justifies the employment of modeling professionals.  I'm not sure that is what your organization is actually hoping to achieve.

• Agile Analysis
• Agile Architectural Modeling
• Agile/Evolutionary Data Modeling
• Agile Model Driven Development (AMDD)
• Agile Requirements Best Practices
• Agile Requirements Change Management
• Comparing the Various Approaches to Modeling in Software Development
• Development Phases Examined: Why Requirements, Analysis and Design No Longer Make Sense
• Database Regression Testing
• Examining the "Big Requirements Up Front (BRUF)" Approach
• Enterprise Modeling Anti-Patterns
• Initial High-Level Architectural Envisioning
• Initial High-Level Requirements Envisioning
• The "One Truth Above All Else" Anti-Pattern
• The Process of Database Refactoring
• The Risks With Traditional Approaches to Modeling