For domain-driven design to work, does an organization need to have good cross-functional communication practices already in place, or does DDD help them build that collaborative relationship?

Cross functional relationships can be built while DDD is being worked on. It is ideal to have the relationships prior to starting DDD work. However, it is not at all practical in this day and age, as there could be a lot of churn in teams. So, there is never a steady state to establish the relationships first and then work on DDD. Doing so would delay the DDD work indefinitely. 

Working on DDD is a great opportunity to continually build the relationships with partner teams. So, once the main stakeholders in cross functional teams have been established, one should embark on DDD work in an agile fashion. I also consider any DDD as a living and breathing artifact as business needs evolve and change over time

DDD does not require that an organization have good cross-functional communication, however for it to used effectively participants may needs an introduction to the DDD concepts in order to best take advantage of it.   Consider doing an exercise to orient the participants to the concepts so that they can better relate the process to your organization.

 It is also important to make sure that you do have active participants from the various departments within your organization.  The idea of DDD is to help clarify and understand the various domains within an organization - which may be different than what was assumed at the start of the design process.  Having strong ground-rules to the process to promote healthy conversation that is open to change is important.

Domain-driven design helps build that collaborative relationship; it’s not necessary for good practices to already be in place. Domain-driven design enhances cross-functional communication and alignment. It helps leaders come together and gives them opportunities to share their perspectives and communicate with each other more effectively.

The extent of collaboration needed depends on the business model and specific needs. In some cases, domain-driven design may not change existing practices due to various business reasons. It’s not that leaders don’t want to work together, but strategic and tactical considerations might dictate otherwise.