A billing schedule is a delivery plan
In the fixed-price projects I have run, billing was tied to milestones: 30 percent as an advance, 40 percent at UAT and 30 percent at production go-live. I like the structure because it says out loud what both sides count as progress.
The advance covers the start and shows commitment on both sides. The middle payment follows the client accepting working software, and the last one follows the system running in production. Money moves at the points where the client can see the result and judge it.
Two details are worth settling before signature: what exactly counts as UAT passed, and what happens to the milestone if the client's side takes longer than planned to test. Left vague, either one turns an invoice into a dispute.
A schedule like this also protects the project's cash position. The team is funded by the advance while it builds, and the last 30 percent gives both sides a reason to finish properly, including the unglamorous parts such as cutover and handover.
Subcontractors are part of the delivery
I have worked with subcontractors who delivered late. I have not had one who failed to deliver at all. The difference matters. Lateness is a management problem: it is visible, it can be discussed and it can often be recovered. Not delivering is a structural problem, and most of the work to avoid it happens before the contract is signed.
For the client there is only one vendor: us. A date missed by a subcontractor is a date missed by the project, and it can push back a milestone and the payment that comes with it. So I treat a subcontractor's plan as part of mine.
When a subcontractor is late, the first thing I do is ask what it needs from us to hit the date. The answer is usually a decision, an environment or an input from our side or the client's, and unblocking it fast is part of my job.
How I manage a vendor who is late
- The same forums. I want the subcontractor in the weekly PM sync and the technical sync, with its risks in the same RAID log.
- Dates tied to outcomes. We agree what will be working and when, not how many hours will be spent.
- Early signals. I would rather hear on Monday that Friday is at risk than on Friday that it was missed.
- Terms that match. What the vendor promises me should line up with what I have promised the client, including acceptance and payment dates.
What a contract is for
A contract is rarely opened when a project goes well. It earns its value when something slips, because it tells everyone in advance what a slip means and who decides what happens next. I try to write it so that it supports the partnership: clear milestones, clear acceptance, no surprises for either side.
That holds in both directions. I have sat on the vendor side and on the customer side, and the contracts that worked were the ones both parties could read the same way.