A few approaches you might consider:
1) Don't start Project A or B until sufficient work (or the whole of) Project I is complete.
2) Since Project I has no external customer value instead of doing it as a separate project, have Projects A and B pick up those elements of it they need when they need them for the customer facing work.
3) Define the interface upfront. If, for example, part of Project I is to create a service that A and B will consume, define what that service needs upfront and ensure that any changes to the interface are communicated between teams so they can adjust as they go.
EDIT - expanding on 3.
This works where the customer facing teams don't need the whole of infrastructure work but will just consume parts of it.
- Infrastructure team is working on an account management system.
- Customer Service team is working on a system for customers to raise
- Finance team is working on a system to allow customers to see their
Customer service team agrees that the infrastructure team will provide an API that allows them to pass a customers email address in and will return some data about the customer account, conforming to an agreed schema that contains information about the customer account allowing them to route the ticket to the right internal team.
The finance team agree that infrastructure will give them a pipe delimited flat file each night, delivered to a certain location via SFTP with a list of all account numbers and their associated balance.
All teams now have a clear understanding of the interfaces between systems and can work under those assumptions. The key with this approach is communicating if agreed dates won't be hit or if any team needs to change the interface for any reason.