Direct answer: A procurement project review and post-evaluation page is not a meeting after the project ends. The page should state: which projects/contracts are reviewed (cost reduction, sourcing, equipment, capex, services, frameworks, supplier exit), when (30/60/90 days after delivery/acceptance, warranty end, annual), goals and baselines (cost/TCO, quality, delivery, risk, compliance, savings), results and variance (actual vs target, finance/quality/delivery/inventory), causes (demand/market/supplier/process/execution), lessons (what worked/failed), improvement actions (templates/policies/suppliers/training/systems), owner/deadline/validation, sharing/archive, public boundary. On the rules: MOF Internal Control Application Guideline No. 16 (Contract Management) Article 16 requires contract performance review/post-evaluation; No. 15 (Comprehensive Budgeting) requires budget execution/analysis/assessment; No. 7 (Procurement) requires plans/contracts/acceptance/payment/records. This article is current to 2026-11-10 and is a summary of public rules and page method, not procurement/finance/audit advice; the company's policies, budget and project data control.
This article is for procurement, finance, quality, planning, internal audit and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby. It covers how to write and accept a procurement project review and post-evaluation page. The usual gap is "success only, no baseline, unexplained variance, lessons not implemented, actions without owners, review as blame, results not shared", ending with a page that only says "continuous improvement, lessons learned", while the next project repeats the same mistakes.
A review is not a celebration/blame session: it needs goals/baselines, results/variance, causes/evidence. Lessons must turn into actions (templates/policies/suppliers/training/systems) with owner/deadline/validation. Reviews must be shared/archived so the next project can use them.
How does this page relate to procurement KPI, internal audit, QIP, contract performance, budget and risk pages?
The review/post-evaluation page answers "how a single project/contract performed, why, and what to change"; the procurement KPI page answers "function-wide KPIs/savings attribution"; the internal audit page answers "control/compliance audit"; the QIP page answers "supplier quality improvement projects"; the contract performance/register page answers "performance/expiry"; the budget page answers "limits/execution/variance"; the risk page answers "risk identification/scoring". The review page is the main page for "post-project evaluation and lessons closed-loop" and cannot be replaced by KPI or audit pages.
Common breaks: success only; no baseline; unexplained variance; lessons not implemented; no owner; review as blame; no sharing; no archive. The page separates "scope—goals—results—causes—lessons—actions—boundary" so procurement/finance/quality/planning/audit share one vocabulary.
| Page | Question it answers | Key content | Cannot replace |
|---|---|---|---|
| Review/post-evaluation | How a project performed/why/change | Goals, results, variance, lessons, actions | KPI/audit |
| Procurement KPI | Function KPIs/savings | Dimensions, basis, savings attribution | Project review |
| Internal audit | Control/compliance audit | Sampling, evidence, remediation | Project review |
| QIP | Supplier quality improvement | Baseline, actions, validation | Procurement review |
| Contract performance/register | Performance/expiry/renewal | Obligations, status, renewal | Post-evaluation |
| Budget | Limits/execution/variance | Budget, commitment, variance | Project causes |
| Risk | Identification/scoring/mitigation | Risk, score, mitigation | Results review |
Page relationships are editorial; the company's policies, budget and project data control.
Which projects should be reviewed, and when?
At minimum: cost reduction/sourcing/tendering, equipment/engineering/capex, services/outsourcing, framework/call-off, new product/NPI, supplier onboarding/exit, major contracts/disputes. Timing: 30/60/90 days after delivery/acceptance, warranty end, annual; major/failed projects immediately. Scope should state project/contract/batch/supplier/period, avoiding "one template for everything"; small projects can use a short form, major/failed projects the full form. State review owner (project manager/procurement/category) and participants (procurement/finance/quality/planning/supplier/customer); link to contract post-evaluation/budget assessment/internal audit. Guideline No. 16 requires contract performance review/post-evaluation.
Acceptance checks: project types; timing; scope; short/full form; owner/participants; linkage. Common gaps: major projects only; no timing; unclear scope; no owner; no linkage.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| Project type | Cost/sourcing/equipment/engineering/services/framework/exit | List | Major only |
| Timing | 30/60/90 days, warranty, annual, immediate | Policy | No timing |
| Scope | Project/contract/batch/supplier/period | Charter | Unclear |
| Short/full form | By value/risk/failure | Template | One-size-fits-all |
| Owner/participants | Project manager/procurement/finance/quality/planning | List | No owner |
| Supplier/customer | Whether to involve/interview | Record | Not involved |
| Contract post-evaluation | Link to contract performance review | Record | Disconnected |
| Budget/audit | Link to assessment/audit | Record | No linkage |
Scope/timing are editorial; the company's policies, project type and budget control.
How should goals and baselines be accepted?
Goals at minimum: cost/TCO, quality, delivery, risk, compliance, savings, cycle time, supplier; baseline at minimum: budget/historical price/market index/quote/standard cost/previous contract. Goals should be quantified, verifiable and time-bound; the baseline should be reproducible, consistent and aligned with budget/finance; do not change the goal/baseline during review "to make the result look good". Goals/baselines are locked at charter/contract/budget stage; changes need records. Savings/cost should distinguish hard savings/PPV/cost avoidance/TCO to avoid double counting. Guideline No. 15 requires a budget basis, No. 7 requires procurement records.
Acceptance checks: goal dimensions; quantification/deadline; baseline source; basis; lock/change; alignment with budget/finance; savings basis. Common gaps: vague goals; arbitrary baseline; baseline changed at review; mixed basis; double-counted savings.
| Element | What to write | Evidence | Common gap |
|---|---|---|---|
| Cost/TCO | Price, TCO, savings | Charter | Unit price only |
| Quality/delivery | PPM/OTIF/acceptance | Quality/planning | Cost only |
| Risk/compliance | Risk, compliance, audit | Record | Risk excluded |
| Cycle time | Sourcing/contract/delivery cycle | System | No cycle |
| Baseline | Budget/history/index/quote/standard | Register | Arbitrary |
| Quantification/deadline | Target/deadline/validation | Charter | Vague |
| Lock/change | Lock/change record | Record | Changed at review |
| Consistent basis | Budget/finance/savings basis | Finance | Mixed |
Goals/baselines are editorial; the company's charter, budget and finance basis control.
How should results and variance be accepted?
Results at minimum: actual cost/savings, quality (PPM/claims/COPQ), delivery (OTIF/delay), inventory/cash, compliance/risk, supplier performance, cycle time; variance at minimum: actual vs goal/baseline (amount/percentage/time), by project/category/supplier; explanation at minimum: demand/market/price/supplier/process/execution/force majeure. Results need finance/quality/planning/warehouse confirmation, not procurement self-reporting; variance should be objective, not "good news only"; failures/overruns must be recorded. Guideline No. 16 requires contract performance review, No. 15 requires budget execution analysis.
Acceptance checks: result dimensions; variance calculation; confirmation; explanation; failures/overruns; evidence. Common gaps: success only; no variance; self-report; no explanation; hidden failures.
| Result | What to write | Evidence | Common gap |
|---|---|---|---|
| Cost/savings | Actual/baseline/savings | Finance | Self-report |
| Quality | PPM/claims/COPQ | Quality | Price only |
| Delivery | OTIF/delay/expedite | Planning | No delivery |
| Inventory/cash | Inventory/terms/cash | Warehouse/finance | Inventory excluded |
| Compliance/risk | Compliance/audit/risk | Record | Risk excluded |
| Supplier/cycle | Performance/cycle | SRM | No cycle |
| Variance | Actual vs goal/baseline | Calculation | No variance |
| Explanation | Demand/market/supplier/execution | Evidence | No explanation |
Results/variance are editorial; the company's finance, quality, planning and project data control.
How should causes, lessons and improvement actions be accepted?
Causes at minimum: demand/specification, market/price, supplier/capacity/quality, process/approval, execution/planning, force majeure; use evidence/data/interviews, not guesswork. Lessons at minimum: what worked (replicable), what failed (avoid), under what conditions; distinguish "luck/individual" from "mechanism/process". Improvement at minimum: templates/clauses, policies/approvals, suppliers/sourcing, training, systems/data, KPIs; each with owner/deadline/validation/closure, included in the next project/annual plan. Guideline No. 16 requires contract post-evaluation improvement, No. 7 requires records. A review is not a report; it changes mechanisms.
Acceptance checks: causes/evidence; worked/failed; conditions; mechanism vs individual; action types; owner/deadline; validation/closure; sharing. Common gaps: guessed causes; success only; empty lessons; no actions; no owner; no validation.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| Causes | Demand/market/supplier/process/execution | Data/interview | Guesswork |
| What worked | Replicable/conditions | Review | Success only |
| What failed | Avoid/conditions | Review | Hidden |
| Mechanism/individual | Separate mechanism from person | Analysis | Blame person |
| Action types | Templates/policies/suppliers/training/systems | Plan | No action |
| Owner/deadline | Who/when/done standard | Register | No owner |
| Validation/closure | Effect/recheck/closure | Record | No validation |
| Sharing/archive | Share/case/archive | Knowledge base | No sharing |
Causes/improvement are editorial; the company's policies, projects and knowledge management control.
How should governance, culture and the public boundary be accepted?
Governance at minimum: review owner/chair, participants, timing, template/short form, quality review, action tracking, annual summary, linkage to budget/assessment/audit/contract post-evaluation. Culture at minimum: focus on issues not people, allow reporting failure, do not turn review into blame, management participation, reward improvement; otherwise people write success only. The public page explains method/process/roles/metrics/boundary and does not publish specific projects/suppliers/prices/savings/failure details/people. Guideline No. 16 requires post-evaluation, No. 15 requires assessment; review results can inform assessment but should not become a "criticism session".
Acceptance checks: owner/chair; participants; timing; template; review; tracking; annual summary; linkage; culture; public boundary. Common gaps: no chair; formality; blame; no tracking; no summary; sensitive disclosure.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| Owner/chair | Project manager/procurement/category | Appointment | No chair |
| Participants | Procurement/finance/quality/planning/supplier | List | Formality |
| Timing/template | 30/60/90, short/full | Policy | No timing |
| Quality review | Data/conclusion review | Record | No review |
| Action tracking | Register/deadline/closure | Register | No tracking |
| Annual summary | Frequent issues/mechanism improvement | Report | No summary |
| Linkage | Budget/assessment/audit/contract | Record | Disconnected |
| Culture/boundary | Issues not people/public boundary | Policy/page | Blame/leak |
Governance/culture are editorial; the company's policies, assessment and knowledge management control.
How should the website page be written, and what must not be published?
Suggested sections: (1) review scope/timing; (2) goals/baselines; (3) results/variance; (4) causes/lessons; (5) improvement/tracking; (6) governance/boundary; (7) contact window/update date. The public page explains "scope, method, metrics, improvement, governance, boundary" and does not publish specific projects/suppliers/customers, prices/costs/savings, failure details/people, contracts or system screenshots. The English page should use consistent terms (procurement post-project review, post-evaluation, baseline, variance, root cause, lessons learned, corrective action, knowledge sharing) and state the cut-off date.
Do not turn the review page into a "continuous improvement/lessons learned" slogan, and do not claim "zero failure/zero overrun" if it cannot be proven. The page should let procurement/finance/quality/planning/audit judge "which projects to review, how to calculate, how to change, who tracks", without exposing project and supplier information.
Go-live acceptance checklist
Ten checks: scope/timing; goals/baselines; results/variance; confirmation/evidence; causes/lessons; improvement/owner; validation/closure; governance/culture; sharing/archive; public boundary. Each needs evidence and a review date. The pass standard is not "there is a review report", but that procurement/finance/quality/planning/audit can judge project results, causes, improvement and closure.
Before go-live, run a tabletop exercise on a real (redacted) project: goals/baselines → results → variance → causes → lessons → improvement → tracking, simulating "overrun", "supplier failure", "goal changed" and "no one tracks", to see whether the page and process work.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Scope/timing | Types/timing/scope/short form | Policy | Add scope |
| Goals/baselines | Quantified/baseline/basis/lock | Charter | Add baseline |
| Results/variance | Cost/quality/delivery/risk/variance | Finance/quality | Add results |
| Confirmation/evidence | Finance/quality/planning confirmation | Record | Add confirmation |
| Causes/lessons | Evidence/worked/failed/mechanism | Review | Add causes |
| Improvement/owner | Templates/policies/suppliers/training | Plan | Add actions |
| Validation/closure | Effect/recheck/closure | Record | Add validation |
| Governance/culture | Chair/participants/no blame | Minutes | Add governance |
| Sharing/archive | Knowledge base/case/archive | Record | Add archive |
| Public boundary | No projects/prices/people | Page/permissions | Take down |
The acceptance list is editorial; the company's policies, budget and project data control.
Who should read it, who should not, and what decisions does it support?
For procurement, finance, quality, planning, internal audit and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby; also for companies handling "success only, no baseline, unexplained variance, lessons not implemented, review as blame". Not for teams without project review/post-evaluation management, or that want one page to replace procurement/finance/audit advice.
Read it if: building a review/post-evaluation page; only "continuous improvement"; success only; no baseline; unexplained variance; lessons not implemented; review as blame. Not suitable if: treating "review" as "celebration/blame"; "lessons" as "a report"; "improvement" as "a slogan"; "page" as "project conclusion/audit opinion". Supports: scope/timing, goals/baselines, results/variance, causes/lessons, improvement/tracking and public-boundary self-checks.
FAQ
What is the difference between the review page, procurement KPI, internal audit and QIP?
The review page answers "how a single project/contract performed, why, and what to change"; procurement KPI answers "function-wide KPIs/savings attribution"; internal audit answers "control/compliance audit"; QIP answers "supplier quality improvement projects". A review is post-project evaluation and does not replace KPI/audit/QIP; the four can reference each other.
Which projects should be reviewed, and when?
Cost reduction/sourcing/tendering, equipment/engineering/capex, services/outsourcing, framework/call-off, new product/NPI, supplier onboarding/exit, major contracts/disputes; 30/60/90 days after delivery/acceptance, warranty end, annual; major/failed projects immediately. Small projects can use a short form; major/failed projects the full form; state owner and participants.
How should goals and baselines be set?
Goals at least cost/TCO, quality, delivery, risk, compliance, savings, cycle time, supplier; baseline from budget/historical price/market index/quote/standard cost/previous contract. Goals quantified/deadline/verifiable, baseline reproducible/consistent with budget/finance; lock at charter/contract/budget, do not change the baseline at review, record changes.
How should results/variance be calculated?
Results cover actual cost/savings, quality (PPM/claims/COPQ), delivery (OTIF/delay), inventory/cash, compliance/risk, supplier/cycle; variance = actual vs goal/baseline (amount/percentage/time), by project/category/supplier; confirmed by finance/quality/planning/warehouse, honestly record failure/overrun, not "good news only".
How should lessons become improvement?
Causes use data/interviews/evidence, separating demand/market/supplier/process/execution; lessons state "what worked/failed/under what conditions", distinguishing mechanism from individual; improvement lands in templates/clauses, policies/approvals, suppliers/sourcing, training, systems/data, KPIs, each with owner/deadline/validation/closure, included in the next project/annual plan, shared/archived.
How to prevent reviews from becoming a formality/blame session?
Management participation, issues not people, allow reporting failure, reward improvement; clear template/timing/chair/participants; data/conclusion review; action register tracking; annual summary of frequent issues; link to budget/assessment/audit but avoid a "criticism session". Review results can inform assessment, but the focus is changing mechanisms.
Should the website publish reviews/savings/suppliers?
Usually not specific projects/suppliers/customers, prices/costs/savings, failure details/people, contracts or system screenshots; it can publish review scope, method, metrics, improvement/governance, public boundary and update date. The goal is to let customers/suppliers understand the procurement-management method, not to disclose project and supplier positions.
One-sentence takeaway
The procurement project review and post-evaluation page on a Changzhou manufacturer's website is not "a meeting after the project ends"; it is about turning scope/timing, goals/baselines, results/variance, causes/lessons, improvement/owner/validation, governance/culture, sharing/archive and public boundaries into a checkable list, so procurement/finance/quality/planning/audit can judge project results, causes, improvement and closure.
Research method and limitations
This article is a summary of public rules and page method, not procurement/finance/audit advice. It uses no unpublished company projects/suppliers/customers, prices/costs/savings, failure details/people, contracts/system screenshots or undisclosed disputes; the tables and acceptance items are editorial and not procurement/finance/audit conclusions. MOF Internal Control Application Guideline No. 16 (Contract Management), No. 15 (Comprehensive Budgeting) and No. 7 (Procurement) are public sources; the company's policies, budget and project data control. This article does not decide whether any specific project/result is reasonable, and does not promise "zero failure/zero overrun"; companies should set them item by item based on project type, category, supplier and finance basis.
Sources and basis
Current to 2026-11-10; the official pages below control.
- MOF Internal Control Application Guideline No. 16 — Contract Management (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Article 16: contract performance review/post-evaluation; used for the review framework.
- MOF Internal Control Application Guideline No. 15 — Comprehensive Budgeting (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Budget preparation, execution, adjustment and assessment; used for goals/baselines/variance/assessment.
- MOF Internal Control Application Guideline No. 7 — Procurement (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Procurement plans/contracts/acceptance/payment/records; used for project evidence/records.