This is the type of project where it pays to spend some time at the beginning to identify external dependencies. A dependency is a potential risk, so if you can identify the nature of the external dependencies, you can put something about those characteristics in the contract with your partner organizations.
To expand on my comment above, you might for example be a provider of a service or data to other organizations. If you know that the mechanism used to offer the data/service can change, and you don't want to support multiple versions of it, you can impose a period for partners to migrate to the new version (say, for ex, 6 months). After the 6 months pass, you decommission the old version and only provide access to the new one. This basically puts a fire under the other organizations' asses (if organizations had asses :)) to make the changes. You basically make it "their problem" with a contract that they agreed to and signed on (it doesn't need to be a specific period, it can also be to conform to new laws and regulations; a good lawyer can phrase it in such a way that the result is the same). This approach removes the dependencies you have on your partners for making the change.
If instead the other organization is a provider for example, and you need them to provide you with something, then this can also be stipulated in a contract as delivery schedules or delivery dates with penalty clauses, etc. They will then be more inclined to respect the contract instead of taking their time with the work or doing it at their own convenience. The problem with this approach though is that they might take some shortcuts or cut some corners to meet the delivery date, and you might have the dependency met on schedule, but what you get back isn't of the quality you would need it to be.
But even if you identified dependencies in the beginning or they just showed up later, it's important to manage them. The problem with external dependencies is is that they are someone else's work. An external dependency is like a promise. Someone promises to do something for you. But then what do you do? Wait for them to keep their promise? Or remind them to keep their promise? With a friend the former might work, in software development I think the later is a much safer bet.
So you can't wait on dependencies or count on the fact that someone is dealing with them. You need to manage them like any other task that you own. That means to have them visible and continually monitored.
Keeping them visible is easy. You can have them in your Kanban board on a different swimlane, attached or marked on other cards of yours, linked within the tools you are using, etc., doesn't really matter. Even if your board should contain your work, and not something others do, it's still your work to make sure others keep their promise (you can't just mark a date in the calendar and get busy with something else, otherwise it's out of sight, out of mind). So you need to find a way to make the dependencies visible.
Then it's all about communication and being informed about progress. You need to know what's going on so you can plan for the dependency (or around it). The sooner you know something is wrong, the better. This won't be easy - as you noticed and mentioned yourself in the post - if there is no pressure or incentive for others to meet your dependency. If you have a good collaboration with the other organization them you can be kept in the loop, otherwise it's just a matter of pressuring them. Too much pressure, and you can easily end up annoying them to the point of them not responding, or saying things like "it will be done soon", "or that they will try", "they will prioritize it above all other work", etc., which translates to "you will get it when you will get it".
So to answer the question, there isn't really an approach or project management process that might be more relevant beyond what you did, simply because the work isn't in your own courtyard. Others can do whatever they want in their courtyards. If there are many unknowns and variables that can't be directly controlled within the project, all you can do is keep things transparent, visible, and monitored. Handle this work others need to do like it's your work within your project, even if your work in this case is holding someone else's feet to the fire for them to keep their promises. And if you can catch this in a contract by spending some upfront time to think about it, then even better.
