When hardware and software teams clash during project deadlines, how do you find common ground?

In Consumer Electronics selling more than 1M units per year, the schedules are Hardware (HW) driven, the Software (SW) has to adapt so that the SW Minimum Viable Product (MVP) is ready when the HW is ready and in Mass Production (MP). After MP, the SW can keep improving over time on the existing HW.

Most of the issues I have seen in this area have been caused by a lack of true understanding of the requirements. Most teams either do not read the documentation early, before the project really starts. This is due to two causes: 1) the team members assume this project is just like all the others; 2) Not enough time is given by management to allow reading the specifications thoroughly. I find it's usually a little of both. Beyond that, the teams really have to communicate on a weekly, if not daily basis. I am not suggesting standing meetings, I'm suggesting working together, discussing assumptions and changes to those assumptions in real time. Never assume the other team knows what you do, and NEVER assume you know what they do.

Yes there are all kinds of tools that help everyone "see" what the other team is doing. My experience is that most of these tools either leave a lot to interpretation, and/or are completely misused and are therefor useless. The best way, in my opinion, to prevent miscommunication is to get up and go talk to the other people. If not co-located, pick up the phone, or better the messenger tool, turn on the camera and talk! Written word is good but way too much is lost in translation and tends to feed disputes. Spoken word AND body language are the best communication tools

Nice goal, but in a largely IP integration project where multiple IP's are being developed simultaneously, Hardware teems are often faced with one IP being late due to complications, while others come in early. Many times the design integrations teams are surprised by this but it's easier for them to adapt and integrate something else. This leaves software teams struggling to keep up as they were focusing on the wrong IP. Software needs to be talking with both the integrations teams AND the IP teams to minimize the damage done to schedules when this occurs

The largest force causing issues here is a "Not my job" attitude. It's Ok too suggest that its not your responsibility, however, if you have the band width and the skill, step up and fix something that is holding up the project EVEN if its not in your scope. The project benefits, the company benefits, and it make you a better team player