When the API is not what was agreed
On one integration the client's API turned out to differ from what had been agreed, or did not exist yet. Our work depended on it, so the delay was not ours to fix. This is one of the most common ways for a fixed-price project to lose its timeline without anyone having done anything wrong.
Why dependencies get ignored
A dependency belongs to nobody on the team, so it is easy to treat as background. The team assumes the other side will deliver, the other side assumes it knows what is expected, and nobody notices the gap until it sits on the critical path. Putting a name and a date on it forces the first real conversation early, while there are still options. I ask for a person as owner, not a department, so there is always someone to call.
What I did
I made the dependency visible early. It went into the RAID log with an owner and a date on the client side, so it was a named commitment and not a vague hope. In every sync I then showed how the delay moved the timeline.
The form I find works best is plain: the planned date, the new date and the reason. No commentary is needed. Both sides can read it, and the question moves from whether there is a problem to what to do about it.
I cannot promise the dependency will arrive. I can promise nobody will be surprised.
What happened, honestly
Visibility did not save the plan. Costs and timeline went up, because the API integration had to be reworked. I do not want to present this as a success story, because the outcome was a bill and a later date.
What visibility changed was the kind of event it was. Because the client had seen the dependency, its owner and the effect on the timeline sync after sync, the increase arrived as a documented and agreed change, not as a surprise at the end. The conversation was about how to handle a known change, not about who had hidden it.
A delay that is announced early can be planned around. A delay that is discovered late can only be absorbed, and on a fixed price somebody ends up paying for the absorbing.
What I do from day one
- External dependencies go in the RAID log from day one, each with an owner and a date on the side that controls it.
- API contracts are agreed in writing before development depends on them.
- The effect on the timeline is shown in every sync, in days, so the delay has a price anyone can read.
- A date that passes is escalated, to the steerco if it has to be, with the options attached.
Where I can, I also ask for a sample response or a mock of the API early, so the team builds against something concrete and not against a description.
The written contract matters most. When the API changes later, the written version is what lets everyone see that it changed, and how much that is worth.