And throw in Conway's law [0] and the scope of the coordination becomes easier to understand.
My career trajectory bought it come for me, intermittently contracting for/with a UK govt acquisition organisation buying systems for Govt customers.
Task: make these disparate systems speak to each other
* Q: Why don't the systems use the same protocols?
* A: They are delivered by different contractors
* Q: Why don't the contractors use the same (existing) standard?
* A: They aren't incentivised to do contractually
* Q: Why do they have different types of contract?
* A: Because each one is contracted by a separate acquisition team
* Q: Why don't the acquisition teams use common requirements / contracting / technical / etc approaches?
* A: Because they are separately funded by different customers
* Q: Why don't the customers speak to each other?
* A: decades of institutionalised rivalries and differences of opinion regarding apparently common problems
It took me about ten years to work down this list, understanding each layer. One of my most satisfying career moments was when I was asked to brief a senior customer decision maker who owned the resulting mess, and drew them a diagram showing the layers. He then set in motion a top-down alignment of the bit he could directly control: requirements writing. The belief was that getting consistent requirements would be a good starting point that would hopefully flow down the organisations involved.
[Edit] Another problem with increasing coherence in this way is that it costs money (e.g. to adopt / set up the standards / protocols involved). Money that could be spent delivering customer requirements, and which PMs are reluctant to spend on 'under the bonnet' techie things the customers won't see let alone understand.
[0] https://en.wikipedia.org/wiki/Conway%27s_law