Project Evaluation Template

In plain language: Names the project, identifies the sponsoring organization and key stakeholders, states the project start and end dates, and summarizes the original purpose and funding authorization.

Common mistake: Omitting the original authorization reference or budget approval number. Without it, the evaluation cannot be cross-referenced against the original project charter, creating disputes over what was actually approved.

In plain language: Restates the original project objectives and agreed scope, then documents which objectives were fully met, partially met, or not met — with evidence for each rating.

Common mistake: Evaluating against an undocumented or informally expanded scope rather than the approved baseline. This lets scope creep go unacknowledged and sets a poor precedent for future projects with the same client or team.

In plain language: Lists each contracted or planned deliverable, records the actual delivery date, acceptance status, and any quality deficiencies noted at handover.

Common mistake: Marking deliverables as accepted without a reference to a signed acceptance record. If a client later disputes quality, an evaluation that says 'accepted' without a linked sign-off document is difficult to rely on.

In plain language: Compares the approved project schedule against actual completion dates, identifies delays with their root causes, and states whether extensions were formally approved.

Common mistake: Reporting schedule variance without documenting whether delays were client-caused, force majeure, or contractor-caused. The distinction determines whether liquidated damages or deadline relief applies.

In plain language: Compares the approved budget to actual expenditure by cost category, explains material variances, and records any formally approved budget amendments.

Common mistake: Presenting a single total variance figure without a category breakdown. A $50,000 overrun that is entirely in one cost line tells a very different story — and has different accountability implications — than the same overrun spread across six categories.

In plain language: Summarizes the risks and issues documented during the project, records the actual outcome of each risk event, and assesses the effectiveness of mitigation actions taken.

Common mistake: Closing the risk log without documenting which risks actually materialized. Future project teams lose the institutional knowledge needed to calibrate risk probability estimates on similar projects.

In plain language: Records performance ratings for key parties — project manager, contractors, vendors, and client representatives — based on agreed criteria such as responsiveness, quality of work, and adherence to obligations.

Common mistake: Using subjective or undocumented rating criteria. If a vendor disputes a poor rating, performance assessments made without reference to pre-agreed KPIs or contract obligations are difficult to defend.

In plain language: Documents specific, actionable insights from the project — process failures, successful practices, and recommendations for improvement — attributed to the relevant project phase.

Common mistake: Writing generic lessons such as 'communicate better' or 'plan more carefully.' A useful lesson names the specific situation, describes the measurable impact, and prescribes a concrete process change.

In plain language: States any outstanding actions required after project close — warranty items, deferred deliverables, unresolved claims, or recommended follow-on work — with named owners and deadlines.

Common mistake: Closing the project without formally assigning post-project action owners. Warranty defects and unresolved issues assigned to 'the team' rather than a named individual are rarely resolved on time.

In plain language: Provides signature blocks for the project manager, project sponsor, client representative, and any other parties required to formally authorize project closure.

Common mistake: Collecting only the project manager's signature and treating the evaluation as complete. Without the sponsor's and client's signatures, the document does not create a mutual record of acceptance, leaving scope and quality disputes unresolved.

A project evaluation is a formal document that assesses whether a project achieved its stated objectives, delivered agreed outputs on time and within budget, and met defined quality standards. It compares actual performance against the approved project baseline, records lessons learned, and provides sign-off by authorized parties to formally close the project. It functions as both an accountability record and an institutional learning tool.

A project evaluation is typically completed at project close, within two to four weeks of the final deliverable being accepted. Some organizations also conduct mid-project gate evaluations at defined phase milestones to decide whether to continue, adjust scope, or terminate. For grant-funded or government projects, the evaluation deadline is usually specified in the funding agreement and must be met to satisfy reporting obligations.

A project status report is a routine in-project update showing current progress, upcoming tasks, and near-term risks. A project evaluation is a retrospective assessment completed at project close or at a major milestone, comparing final outcomes against the approved baseline. Status reports inform decisions during delivery; evaluations inform accountability, payment, and lessons learned after delivery.

At minimum, the project manager and the project sponsor should sign to confirm the findings are accurate. For client-facing projects, the client representative or authorized recipient should also sign to acknowledge acceptance of deliverables and agreement with the evaluation conclusions. In regulated industries or government contracts, additional sign-offs from a quality assurance officer or funding-body representative may be required.

When properly executed with authorized signatures, a project evaluation can serve as a formal record of acceptance that is generally relied upon in contractual disputes. It establishes that deliverables were accepted, variances were documented and acknowledged, and the project was closed by mutual agreement. Consider consulting a lawyer if the evaluation will be used to settle disputed claims or release retainage in a construction or services contract.

Effective lessons learned entries identify the specific project phase in which the issue or success occurred, describe what happened and the measurable impact it had, and prescribe a concrete process change for future projects. Generic observations such as 'communicate better' are not useful. A well-written lesson names the situation, quantifies the consequence — for example, a two-week delay caused by late client approvals — and recommends a specific mitigation such as adding an approval deadline to the project schedule template.

A standard project evaluation template covers the core elements applicable to most projects — scope, budget, schedule, deliverables, risk, and lessons learned. However, specific project types may require additional sections: construction projects typically include a defects liability period review, IT implementations add a system performance baseline comparison, and grant-funded projects require outputs mapped to funder KPIs. Adapt the template's section headings and rating criteria to match the governance requirements of the specific project type.

A project evaluation is typically conducted by the project team and sponsor as part of normal project governance. A project audit is an independent review conducted by a third party — internal audit, an external firm, or a funding body — that examines whether project processes, controls, and expenditure complied with applicable standards and agreements. Evaluations are collaborative; audits are independent and may be triggered by concerns rather than routine closure.

Overruns documented in a project evaluation should be analyzed for root cause and classified as contractor-caused, client-caused, or attributable to external factors. This classification determines whether additional costs can be claimed, whether liquidated damages apply, or whether a change order should be issued retrospectively. Significant unresolved overruns should be escalated to the project sponsor before sign-off, and legal advice is recommended before releasing final payment or retainage.