The AI report says 90% complete. Is that defensible?
An AI summary describes the release as 90% complete and low risk. You must give the sponsor a useful update.
The question
Alder Works and all statuses are fictional. The ten milestones have equal reporting weight. The agreed metric is milestones accepted by the named business owner; it is not effort or schedule progress.
| Milestones | |
|---|---|
| Accepted | 6 |
| Delivered; acceptance pending | 3 |
| Not delivered | 1 |
The AI counted accepted and delivered milestones together. The register has ten milestones in total.
- SponsorReport accepted milestones, the forecast finish, blockers and decisions needed. A percentage alone is not a forecast.
“Choose your next action and explain the evidence behind it.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: What does 90% measure?
What would you do here? Open the move you’d make.
Separate delivery and acceptance
The strong move. Delivered and accepted are different states.
Use 90% because the AI read the register.
Tempting, but it misses something. Accurate extraction does not make its definition correct.
See how a strong candidate says it
“It counts 9 delivered milestones. The agreed accepted measure is 6 / 10 = 60%.”
Why it works: Delivered and accepted are different states.
Step 2: Can you infer the finish date?
What would you do here? Open the move you’d make.
Ask for remaining estimates
The strong move. Equal reporting weights do not imply equal remaining duration.
Assume only 10% of the planned time remains.
Tempting, but it misses something. Milestone counts cannot establish a time forecast.
See how a strong candidate says it
“Ask milestone owners for remaining acceptance work, dependencies and estimates.”
Why it works: Equal reporting weights do not imply equal remaining duration.
Step 3: How does the audit change status?
The acceptance owner reopens one of the six accepted milestones after a failed retest. No other milestone changes state.
What would you do here? Open the move you’d make.
Update the accepted count
The strong move. The current accepted count must reflect the failed check.
Keep 60% until the next reporting cycle.
Tempting, but it misses something. That knowingly reports an outdated status.
See how a strong candidate says it
“Report 5 accepted, 1 reopened, 3 pending acceptance and 1 not delivered: 50% accepted.”
Why it works: The current accepted count must reflect the failed check.
Step 4: What do you escalate?
The remaining undelivered milestone requires a vendor security approval. The vendor has not committed to a review date. There is no approved route around that gate.
What would you do here? Open the move you’d make.
Escalate the undated gate
The strong move. An unknown required dependency must be visible before promising a finish.
Keep the low-risk label because the other milestones look healthy.
Tempting, but it misses something. A label cannot resolve a required approval.
See how a strong candidate says it
“Name the missing security approval, ask its owner for a date and show the resulting forecast uncertainty to the sponsor.”
Why it works: An unknown required dependency must be visible before promising a finish.
The answer, in short
- Decision
- Correct the report and obtain an owner-backed forecast.
- Because
- Only five milestones remain accepted, and the final gate has no committed date.
- What would change it
- Verified acceptance or a dated vendor commitment.
Common traps
- A precise percentage can use the wrong definition.
- Completion percentage is not a finish-date model.
Check your answer
- I reconciled all ten states.
- I separated delivery from acceptance.
- I updated reopened work.
- I named the uncertain dependency.
Last reviewed Nov 10, 2026