Project Milestone Rejection Reason Mix

A team submits a project milestone for acceptance and the reviewer rejects it or returns it for more work. Rejection reason mix groups the recorded causes so the project can fix repeat problems rather than only counting failed submissions.

Begin with a clear population of submitted milestones with a formal rejection or return during a stated period, excluding informal draft comments unless the metric explicitly covers them. Define the unit, since one milestone may be rejected twice, and decide whether to count rejection events, unique milestones or final outcomes, then show the chosen denominator.

Capture the review decision in a system record that links it to the correct milestone version, as Oracle project guidance describes milestones with statuses and possible completion approval. Use counts with percentages, because two rejections out of three reviews are different from two out of 300.

Agree on reason categories that fit the project's work, such as missing evidence, unmet acceptance criteria, incomplete testing, scope disagreement and wrong approver. Avoid blame labels, since a missing test report can reflect a weak handoff rather than an individual fault, so code the observable gap and then investigate process causes.

Allow a primary reason and notes because several issues can appear in one review, and if using only one code, define how the primary cause is selected. An illustrative mix is 12 rejection events: five missing evidence, four failed tests and three scope disputes, with shares of about 41.7%, 33.3% and 25%, which describes only the classified events in this example.

Check unclassified items, because a large other category means the taxonomy is weak, so review notes and update categories without rewriting past results silently. Link each rejection to the agreed acceptance condition, since a reviewer's new preference is not automatically a valid contract requirement.

Distinguish technical failure from paperwork, because a product may work but lack the required evidence while another may have complete paperwork but fail a test, and the remedies differ. Check version history, since a second rejection may be for a new issue or an unresolved first issue, and preserve the earlier comments and resubmission date.

Compare by project phase, because design approvals, factory tests and handover documents have different criteria and one aggregate mix can conceal a local problem, and track time to rework so that cycle time shows the resulting delay alongside the reasons. Include reviewer differences, since if one reviewer rejects many submissions for a criterion others never mention, the standard needs clarifying rather than objective quality rules being changed solely to lower the count.

Watch for premature submissions that shift rework into the customer review, check scope changes so a valid submission is not rejected under outdated criteria, assign corrective action with an owner and later verification, preserve consistent definitions when trending cause changes, and keep decision records while protecting confidential design or pricing details under policy. For owners, rejection reason mix turns repeated returns into a practical improvement list, and many returns are normal review steps, so the aim is clearer criteria and stronger first submissions, not pressure on reviewers to approve weak work.