Do the Applicant's contracts define project phases / milestones?
Most professional liability claims are scope disputes wearing other clothes. Milestones are how scope stays visible.
What the carrier is actually asking
The carrier is asking whether project work is structured into defined phases with milestones, deliverables, and associated payments, rather than being open-ended.
Why it is underwritten
Undefined scope produces the divergence between what the client expected and what was delivered, which is the origin of most professional liability claims. Milestones create checkpoints where that divergence is visible and correctable while it is still small.
Where the answer lives in Microsoft 365, Entra ID, and Azure
This is a contracting and delivery practice question.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Contracts | Statements of work with phases, deliverables, and milestones | Defined deliverables with dates and acceptance criteria per milestone. Attested |
| Change control | The process for varying scope | A written change process, since scope creep without change control is the classic dispute pattern |
| Delivery records | Milestone completion records and client communications | Evidence that milestones were reached and acknowledged |
| Payments | Whether payment is tied to milestones | Payment linked to acceptance, which creates a natural checkpoint |
| Dependencies | Client obligations per phase | Documented, since delays caused by the client are a frequent source of dispute |
Projects rarely fail at a milestone. They fail because twenty small unrecorded changes accumulated until the delivered scope no longer resembled the agreed one, and neither party can say when the divergence happened. A change process that people actually use is the control.
What a defensible yes requires
- Work is structured into phases with defined deliverables and criteria.
- A change control process exists and is used rather than bypassed.
- Milestone completion is documented and acknowledged.
- Payment is tied to milestone acceptance.
- Client dependencies are documented per phase.
How this answer goes wrong
The statement of work defines phases and no change control is applied in practice, so requests are absorbed informally. When the project overruns, there is no record of what was added, and the dispute is about the entire engagement rather than about the changes.
Frequently asked
Does agile delivery conflict with this?
No. Sprints and releases are milestones. What matters is that scope and acceptance are visible at intervals, which agile does well when documented.
What if clients resist change control?
Keep it lightweight: a written note of the change and its impact, acknowledged by email. The record matters more than the formality.
Should payment follow milestones?
Where possible. It creates a natural checkpoint and limits how much unpaid work accumulates before problems surface.
How detailed should deliverables be?
Detailed enough that both parties would agree whether one was delivered. That is the practical test.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture