All depends on what modelling methods you use. The ORM "Rmap" approach for example derives the final database implementation directly from the conceptual model. So getting the conceptual model correct is the most critical aspect of the design process. Object Role Modeling
ER diagrams are very limited in the range of relationships, constraints and other options that can be properly expressed. Typically an ER diagram doesn't capture enough information to allow for complex data modelling as well as an effective implementation of that model. That's why it's common to take a staged approach, where the model is progresively refined and adjusted, beginning with a Description of what's being modelled and ending with a Design of a database.
Many software development projects today also use Agile methods. In that case I find it useful to create smaller, subject-area models that are shared with the team in each sprint / iteration and that will probably be much closer to what is actually implemented rather than what is conceptually being represented - i.e. model as Design rather than Description.
Without it being a formal process, I would say that I do tend to start with a CDM, i.e. an ERD without the attributes filled in, as a way of understanding the broad data requirements. I don't call it a CDM though, if pushed I'd probably have just called it a sketchy, overview LDM.