What I have learned to expect
In my experience, the client's environments are always delivered late. So are the client's resources: the people who have to grant access, answer questions or take part in testing. I treat it as a planning input, not as an exception.
For example, a typical case is a test environment that exists on paper but has no accounts, no certificates or no sample data yet. The environment is then formally delivered and still unusable, which is harder to spot and to escalate than one that is plainly missing.
Whatever form the delay takes, it changes how I build a plan. The first weeks should contain work that does not depend on the client at all, such as the core of the application, the data model and the automated tests. Work that needs the client's systems comes later in the plan, with room around it.
Putting that work first matters because it keeps the team busy on real progress, not on filler. When the environment finally arrives, the integration work meets a product that is already stable and tested, and the late start costs far less than it could have.
Adapting as the vendor
As a software vendor, I cannot ask a staffed team to sit and wait. On a fixed price, every idle day is paid for by the vendor. Being right about whose delay it is does not return that day. So the team has to be ready to go the moment the environment arrives, and useful before it does.
What ready means
- Our own environment first. A development and test setup that we control, so daily work does not depend on the client's.
- Stand-ins for what is missing. Mocks and sample data for the systems we cannot reach yet.
- Deployment prepared. Scripts and configuration written ahead, so the first deployment to the client is a routine step.
- A written request, made early. What we need, in what form, by when and from whom.
Make the dependency visible
I put the environment dates in the offer as assumptions and in the RAID log as dependencies, each with an owner on the client side. When a date slips, I say so at once, with the impact in days, in the forum where someone can act on it. That is the no-surprises principle applied to something very ordinary.
The same applies to people on the client side. I ask for a named contact and a backup for each dependency, because a single person who is busy elsewhere can stall a whole week. A name and a date are easier to follow up than a general promise that someone will help.
End-to-end availability is the same story at a larger scale. A flow that crosses several systems only works when every environment in the chain is up, with data that fits together. I ask early who owns each link, and I try to rehearse the full chain before the formal testing starts, so that the first real end-to-end run is not also the first time anyone has looked at it.
Be right about the dependency, but be ready regardless.
I do not say this to blame the client. A client has its own priorities and its own queue of requests. The goal is a partnership in which late environments are expected and planned for, so that nobody has to be defensive when they arrive.