---
title: "Do the Applicant's contracts define project phases / milestones?"
url: https://insuranceposture.com/questions/services-and-contracts/applicant-s-contracts-define-project-phases-milestones
category: "Services and contracts"
canonical_key: q_pro_015
evidence_state: attested
updated: 2026-08-24
---

# Do the Applicant's contracts define project phases / milestones?

URL: https://insuranceposture.com/questions/services-and-contracts/applicant-s-contracts-define-project-phases-milestones
Section: Services and contracts
Evidence state: Attested, not tenant-verifiable

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 |

**Change control is where projects fail**

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.

## If this answer turns out to be wrong

Technology E&O questions describe what you promised your own clients, and the policy language decides how strictly your description of that is held. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [whether an answer is a warranty or a representation](https://insuranceposture.com/glossary/warranty). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary).

## 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

- [Do the Applicant's contracts include customer acceptance / final sign-off?](https://insuranceposture.com/questions/services-and-contracts/applicant-s-contracts-include-customer-acceptance-final-sign-off)
- [Does the Applicant enter into contracts with fees contingent on client outcomes?](https://insuranceposture.com/questions/services-and-contracts/applicant-enter-into-contracts-fees-contingent-client-outcomes)
- [Does the Applicant use written contracts or agreements with its customers for the provision of services or products?](https://insuranceposture.com/questions/services-and-contracts/applicant-written-contracts-agreements-customers-provision-services-products)
- [Do the Applicant's client contracts address guarantees or warranties?](https://insuranceposture.com/questions/services-and-contracts/applicant-s-client-contracts-address-guarantees-warranties)

---

Insurance Posture by SecValley. https://insuranceposture.com
The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished.
SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact.
Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.