Capstone: closing projects and phases, with exam strategy

Projects are temporary, so every project ends, whether it delivers everything, delivers part, or is canceled. Closing is where many projects become careless: the team drifts to new work, contracts are left open, lessons are not captured, and the operations team inherits a product without the knowledge to run it. This capstone lesson covers closing a project or phase, closing procurements and transitioning the product, using the end of Project Compass as the example. It then pulls together quality, risk, procurement and integration into a strategy for the exam questions on these topics.

What closing involves

Closing a project or phase finalizes all activities for the project, phase or contract. Its purposes are to confirm that the work is complete and accepted (or to document why it was not), to transfer the product to those who will use and support it, to close contracts and finances, to capture knowledge, to release people and resources, and to archive records. Closing applies at the end of each phase as well as at the end of the project: Project Compass closed its design phase when drawings were approved and its fit-out phase at substantial completion, each with a short closure review.

Administrative closure is the term often used for the internal steps: collecting records, analyzing success and failure, gathering lessons, and archiving. Contract closure covers the procurements. Both are needed; a project with a completed final report but open contracts is not closed.

Closing procurements

Closing a procurement confirms that the seller has delivered everything required and the buyer has met its obligations. The buyer verifies that all deliverables have been accepted, resolves open claims, makes final payments, releases holdbacks or retainage when the contract allows, confirms warranty terms, and gives the seller formal written notice that the contract is complete. A procurement audit, a structured review of the procurement process from planning to closure, captures what worked and what did not for future procurements.

Disputes should be settled before closure wherever possible, through negotiation or the contract's dispute resolution steps (lesson 9). Contracts can also end early: by mutual agreement, for the buyer's convenience if the contract allows, or for default if a party fails to perform. Early termination still requires closure, including settlement of the work done to date.

For Project Compass, the fit-out contract could not be closed at substantial completion, because retainage was held until final completion and the contractor's lien waivers were received. The kiosk contract was closed after acceptance, with the final price confirmed under the FPIF terms. The app contract closed after release 2, with source code, documentation and accounts handed over as the contract required. At the time of the final report, the fit-out contract was still open pending final completion items: it is one of the two items still open on the closure checklist below; the other is the final report itself, which went to the board the following week.

The kiosk vendor's actual cost, disclosed for the incentive calculation, came to $318,000, below the point of total assumption of $321,400. Its fee was $30,000 − 30 % × $18,000 = $24,600, so the library paid $342,600, under the $345,000 ceiling. The incentive structure worked as intended: the vendor carried part of the overrun, and the library's exposure stayed below the ceiling.

Final performance and the final report

# Closing Project Compass: final performance against the original and revised baselines ($000)
bac = 2400
approved_changes = 18                 # CR-02, CR-03 and CR-06 from the change log
mgmt_reserve_released = 120           # approved by the sponsor in month 7
board_top_up = 50                     # extra funding approved by the board in month 7
revised = bac + approved_changes + mgmt_reserve_released + board_top_up
final_cost = 2571
print(f"Original BAC {bac:,}  revised cost baseline {revised:,}  final cost {final_cost:,}")
print(f"Against original BAC: {final_cost - bac:+,} ({(final_cost - bac) / bac:+.1%})")
print(f"Against revised baseline: {final_cost - revised:+,}")
planned_days, actual_days = 100, 108
print(f"Fit-out critical path {actual_days} vs {planned_days} working days "
      f"({actual_days - planned_days:+d}; the Monte Carlo P50 was about 108)")
checklist = {
 "Sponsor acceptance of all deliverables signed": True, "All procurement contracts closed": False,
 "Final lessons learned workshop held": True, "Records archived in the library's records system": True,
 "Team members released with performance input": True, "Operations handover and warranty list": True,
 "Benefits measurement plan handed to branch manager": True, "Final report issued to the board": False,
}
print(f"\nClosure checklist: {sum(checklist.values())}/{len(checklist)} complete")
for k, v in checklist.items():
    if not v:
        print("  open:", k)

Original BAC 2,400  revised cost baseline 2,588  final cost 2,571
Against original BAC: +171 (+7.1%)
Against revised baseline: -17
Fit-out critical path 108 vs 100 working days (+8; the Monte Carlo P50 was about 108)

Closure checklist: 6/8 complete
  open: All procurement contracts closed
  open: Final report issued to the board

The branch opened eight working days later than the baseline plan, close to the P50 of about 108 days from PMP-130's schedule simulation, and within the window the board was told to expect after the permit delay. The final cost of $2.571 million was $171,000 (7.1 %) above the original BAC of $2.4 million, but $17,000 below the revised baseline of $2.588 million that the board approved in month 7 after the month 6 forecast, once the management reserve, the $50,000 top-up and the approved changes were included. Quality results were good: the gate read rate averaged 99.7 %, kiosks completed 98.6 % of checkouts unassisted in the first month, the app had 99.3 % crash-free sessions, and the accessibility review found no nonconformities.

The final report summarizes the project's performance against its objectives: scope delivered, quality results, schedule and cost against original and revised baselines with explanations, risks that occurred and how they were handled, benefits expected and how they will be measured, and recommendations. It should be honest about variances. The Compass report explains that the cost overrun came mainly from construction unit costs above the estimate and slower initial tagging, that the overall cost risk had been flagged at baseline with a low confidence level, and that the board's early decision in month 7 allowed corrective actions to limit the final overrun.

Lessons learned and transition

The final lessons learned workshop brought together the library staff, the architect, the contractor's site lead, the kiosk vendor and the app team. Lessons are recorded in the register and, where they apply beyond this project, used to update the library's templates and procedures. Among the nine new entries: complete the permit submission checklist before applying; include tariff and duty provisions in supply terms rather than accepting pass-through by default; run Monte Carlo cost analysis before setting public budgets; put a two-week soak test into every kiosk contract; and check building service responsibilities in the lease as part of risk identification.

Transition is where the project's output becomes the organization's asset. The branch manager received operating manuals, a list of warranties with expiry dates, support contacts and service levels, training records, the configuration register for kiosk firmware, and an issues list of minor items with owners and dates. Benefits, such as visits, loans and community room bookings, will be measured by the branch manager at 6 and 12 months against the business case; benefits realization belongs to the business owner, and PMP-150 covers it in depth. The project team was released with written input to each member's performance review, a step PMP-120 recommended, and the team celebrated the opening with the branch staff.

Closing in adaptive and terminated projects

Adaptive projects close continuously in small ways: each increment is reviewed and accepted, retrospectives capture lessons as the work proceeds, and the product owner decides when enough value has been delivered to stop. Final closure still involves handover to operations or a product team, closing contracts, final reporting and archiving. For the Compass app, ongoing development passed to the library's digital services team, with the backlog of future features, the source code and the test suite.

A project that is canceled before completion also needs closure. The reasons for termination are documented, work completed is assessed and, where useful, handed over, contracts are terminated according to their terms, people are released and lessons are captured. A well-closed canceled project protects the organization's money and learning; a canceled project that is simply abandoned wastes both.

Exam strategy for quality, risk, procurement and integration

Questions on these topics follow recognizable patterns. Most are situational: a scenario followed by "what should the project manager do next?" or "what is the best action?". A smaller number are calculations. A structured approach helps.

For situational questions, read the last sentence first to see what is asked, then identify the topic and the stage of the project. Ask what has already been done in the scenario: if a risk has occurred and a contingency plan exists, implement it; if not, it is a workaround or an issue. Prefer answers that analyze before acting, follow the agreed processes and plans, involve the right people, and address causes rather than symptoms. Be wary of answers that are passive (wait and see), that bypass governance, or that blame individuals. Finally, notice the approach: in an agile scenario, backlog reprioritization and team decisions often replace formal change requests and inspections.