Project Milestone Evidence Acceptance Rate

A project plan says a milestone is done, but the customer has not accepted the deliverable and the required test record is missing, so project milestone evidence acceptance rate measures the share of declared completed milestones whose applicable proof passes authorised review. A milestone is a significant project event, not necessarily every routine task, and PMI's project lexicon defines acceptance criteria as conditions met before deliverables are accepted.

APQC discusses reviewing progress and lessons at key milestones, so these sources support evidence-led checkpoints rather than treating schedule colour as proof. Set criteria from the project agreement and approved acceptance plan to specify each milestone's conditions, and identify the reviewer, since internal quality, customer approver and regulator can have different roles and authority.

Define the evidence, such as test results, signed deliverable receipt, inspection photos or operational demonstration, and avoid checkboxes alone, because a form marked passed without relevant records should fail evidence review. A design approval and a physical installation need different proof and reviewers, and critical work may require an inspection even if a customer is happy with the visible result.

Check the evidence itself. The test must apply to the deliverable version submitted for acceptance, a document can be linked but unreadable, from the wrong site or missing a page, and a supplier certificate may help but still need matching lot, site and specification.

Evidence should connect to a work order, test or deliverable ID rather than a loose unlabelled file, independent validation can be part of the agreed acceptance criteria, and the dates for work completion, evidence collection, acceptance decision and invoice eligibility should be recorded separately because they may differ. Separate readiness from acceptance, since a team can believe a deliverable is ready while the customer has not yet reviewed it, and track reviewer availability so a deliverable waiting for an authorised reviewer is reported as a queue rather than called defective or the customer unresponsive without evidence.

Show open age, because a milestone waiting for acceptance may delay billing or handover even if technical work is done. Do not present internal completion as signed customer acceptance, which would damage customer trust.

Handle conditional acceptance by stating whether a customer accepting subject to listed defects counts and by preserving the punch-list items, and respect the contract, since some agreements define deemed acceptance after notice but that mechanism should not be assumed to exist globally. Track rejection, because a reviewed milestone may fail criteria and require rework rather than disappear from the denominator, and preserve objections by saving the exact grounds and the corrected resubmission rather than replacing the first decision, which can explain schedule movement.

Report accepted, rejected, conditional and pending states as distinct outcomes. Choose the cohort as milestones declared complete in a period, with pending reviews shown separately, and define the denominator so that a cancelled milestone under an approved scope change is not treated as failed completion.

Watch scope changes, since updated criteria after an approved change should replace outdated tests with traceable history, and keep approved scope deletions in the decision log with the date they took effect so a later report can state whether its cohort uses the plan at period start or the current plan, which keeps rates comparable. Avoid a premature invoice, because a billing trigger may depend on acceptance rather than task status, and use the rate to make project progress credible and help teams correct the actual gaps before handover.