There can be a lot of people from many parts of an organization involved in a software project and it might really be impossible to get everyone together all the time. The risk is when ideas are communicated from the customer to one person who then has to translate those ideas to the people developing the software. Just like in the game telephone ideas get altered and assumptions lost.
When the developers and customers don't communicate you also lose the negotiation that might happen. This negotiation allows potential problems to be brought into the light before any code is actually written.
With increased communication you can also negotiate reducing the complexity in the requirements. If you have a complex business process you'll want to simplify it as much as possible. Complexity goes hand in hand with problems, and not simple problems. Problems as complex as the process itself so they're hard to track down.
One of my favorite phrases is 'You ain't gonna need it' (YAGNI). Half of the software developed will never be used, so cut out as much of it as possible before actually building anything.
Get Feedback as Quickly as Possible
Once you have a good plan in place with the absolute minimum requirements needed its time to start building something. This is where the assumptions that people have start to come out and things can go off course really quickly. This is why it is imperative to get feedback as quickly as possible from the customer. Let them see what you're doing and have them validate that it is correct and do it while it's still fresh on everyone's mind.
One way to measure this is your cycle time. How fast can you go from idea to a released feature. The quicker you can do that the easier it will be to change what isn't going to work.
Plan to Change
When managing a complex project there is only 1 reliable truth: the plan is going to change. You'll need to make sure that change is understood to be a good thing. It will allow the project to deliver real value and be useful.
Change has a reputation for being bad. For some projects that might be justified, but for complex projects, like software, you need to assume that your assumptions are wrong and you need to learn what is right along the way.
Build in Quality
And lastly, don't compromise quality. It will be tempting with pressures building, but if you do compromise quality you run the risk of introducing dumb little bugs that have you face-palming yourself.
You should be proud that you were part of a project and do everything you can in order for it to be the best you could possibly make it.
Following these general principle will help wrangle the risk we all face whenever we start complex projects. We'll never eliminate it all, but we can do our best to improve our chances to make it a successful project.