# Project Execution Plan

## Overview

This resource is a practical, modular Project Execution Plan template and guide for owner-side corporate real estate and capital projects. It helps project teams define how a project will be planned, governed, managed, reported, controlled, turned over, and closed out from the owner's perspective.

The template is designed for corporate real estate project managers, construction managers, workplace and facilities leaders, finance partners, procurement partners, project sponsors, and capital governance stakeholders who need a clear execution framework for commercial office, workplace, R&D, lab, manufacturing, logistics, campus, tenant improvement, build-to-suit, and major capital improvement projects.

## At a Glance

| Field | Summary |
| --- | --- |
| Resource type | Project Execution Plan template and owner-side execution guide |
| Primary use | Planning, governing, reporting, controlling, and closing out corporate real estate and capital projects |
| Best fit | Owner-side project teams managing multi-stakeholder projects with budget, schedule, risk, approval, or turnover requirements |
| Not intended for | Contractor means and methods, legal advice, engineering design, safety program substitution, or regulatory compliance determination |
| Recommended review | Project sponsor, owner-side project manager, finance, procurement, legal, EHS, facilities/operations, and qualified design or construction professionals as applicable |

## Intended Audience

This template is intended for owner-side corporate real estate project managers, construction managers, workplace project leads, facilities leaders, finance partners, procurement partners, project sponsors, real estate leaders, owner representatives, and capital project leaders.

It may also be useful for consultants, construction managers, architects, engineers, vendors, and delivery partners who need to understand the owner's governance, reporting, decision-making, and closeout expectations.

## When to Use This Resource

Use this template when initiating, planning, governing, or resetting an owner-side corporate real estate or capital project that needs a practical execution structure. It is intended to help the project team define how the project will be governed, managed, reported, controlled, and closed out from the owner perspective.

Recommended use cases include:

- New capital projects requiring project governance and controls.
- Tenant improvement, workplace, office, lab, R&D, manufacturing, logistics, campus, build-to-suit, or major capital improvement projects.
- Projects with multiple stakeholders, approval requirements, budget exposure, schedule commitments, operational readiness needs, or executive reporting requirements.
- Projects that need a clear owner-side framework before design, procurement, construction, commissioning, turnover, or closeout activities accelerate.

## What This Template Covers

The Project Execution Plan provides a structure for:

- Document control and project summary information.
- Project classification, complexity, and controls level.
- Business objectives, success criteria, and scope definition.
- Delivery strategy, governance, roles, responsibilities, and stakeholder management.
- Communication, reporting, budget, cost, schedule, risk, and change management.
- Executive reporting and optional appendices for procurement, design, permitting, quality, safety, commissioning, KPIs, sustainability, document control, lessons learned, and project logs.

## What This Template Does Not Cover

This is not a general contractor field execution plan or a means-and-methods document. It does not replace project-specific contracts, professional design documents, safety plans, legal review, procurement requirements, authority approvals, code analysis, company policies, or regulatory compliance obligations.

The template should be treated as an owner-side governance and execution document that aligns the owner, project sponsor, stakeholders, consultants, delivery partners, vendors, and executive approvers around the approved scope, budget, schedule, risks, decisions, governance model, and success criteria.

## Free Template and Customization Options

This free Project Execution Plan template is designed to provide a practical, owner-side starting point for corporate real estate and capital projects. Users may download, review, and adapt the template for their own project needs.

For project-specific use, the template should be reviewed and tailored to the applicable company policies, project type, intended facility use, location, delivery method, contract structure, governance model, approval authority matrix, reporting cadence, safety requirements, permitting requirements, currency, language, and corporate standards.

A customized REWS.AI version may help users create a project-specific draft more efficiently by adapting the template to selected inputs such as company name, project name, project location, project type, delivery method, governance structure, approval thresholds, contract interfaces, and local requirements. Any customized output should still be reviewed, modified, and approved by qualified professionals before use.

## Disclaimer, Limitations, and Professional Review

This Project Execution Plan template is provided for general informational, educational, and project management reference purposes only. It is not intended to constitute, and should not be relied upon as, legal, engineering, architectural, construction, safety, environmental, accounting, tax, procurement, code, regulatory, financial, insurance, or other professional advice.

Users are solely responsible for reviewing, modifying, approving, and implementing this template for their specific project, organization, contract structure, delivery method, facility use, jurisdiction, and applicable requirements. This template does not replace project-specific contracts, company policies, approval authority requirements, professional design obligations, safety obligations, procurement requirements, financial controls, insurance requirements, legal review, code analysis, permitting requirements, or regulatory compliance obligations.

Before using this template on a project, users should consult qualified professionals as appropriate, including legal counsel, licensed architects and engineers, contractors, construction managers, safety and EHS professionals, finance and accounting advisors, procurement professionals, insurance and risk advisors, authorities having jurisdiction, and company leadership.

This template is provided "as is" without warranties of any kind, whether express or implied, including but not limited to warranties of completeness, accuracy, fitness for a particular purpose, compliance with applicable laws or regulations, or suitability for any specific project. REWS.AI does not assume responsibility for any project outcome, decision, action, omission, cost, delay, claim, loss, noncompliance, injury, or damage arising from use of, modification of, or reliance on this template.

Any customized version generated through REWS.AI should also be reviewed, modified, and approved by qualified professionals before use, issuance, reliance, or implementation. Professional review is especially important for projects involving regulated uses, manufacturing, laboratories, cleanrooms, data centers, healthcare, hazardous materials, life safety systems, occupied facilities, public access, critical infrastructure, major capital projects, complex delivery models, or unfamiliar jurisdictions.

## Using This Template

This template is intended to provide a practical starting point for preparing a Project Execution Plan for owner-side corporate real estate and capital projects. It helps owner-side project managers organize the project execution approach, align stakeholders, document governance expectations, and establish practical controls for scope, budget, schedule, risk, change, reporting, turnover, and closeout.

Users should review each section, replace bracketed fields such as [Project Name], [Company], and [Location] with project-specific information, remove or mark sections that do not apply as "Not Applicable," and add company-specific, project-specific, location-specific, contractual, regulatory, safety, and governance requirements as needed.

Each section and appendix should be adapted based on the project type, intended facility use, company policies, location, delivery method, contract structure, governance model, approval authority matrix, reporting cadence, safety requirements, permitting requirements, currency, language, and corporate standards. Additional company-specific requirements, project controls, approval processes, safety requirements, regulatory requirements, and professional review requirements should be added where appropriate.

The full template is intentionally modular. Users may prepare a shortened project-specific version by keeping the applicable core sections and appendices, removing sections that are not relevant, or marking non-applicable sections as "Not Applicable."

The document should be reviewed by qualified professionals before use. Throughout this template, "REWS.AI Customization Notes" identify areas that commonly require project-specific, company-specific, or location-specific adaptation. These notes are intended to help users understand what should be reviewed and tailored before using the document on a live project.

## Core Project Execution Plan

1. Document Control
2. Project Summary
3. Project Classification
4. Project Complexity and Controls Level
5. Business Objectives and Success Criteria
6. Scope of Work
7. Project Delivery Strategy
8. Governance and Decision-Making
9. Roles and Responsibilities
10. Stakeholder Management
11. Communication and Reporting Plan
12. Budget and Cost Management
13. Schedule Management
14. Risk and Change Management
15. Executive Summary and Reporting Snapshot

## Optional Appendices

A. Procurement and Contracting Strategy
B. Design Management
C. Permitting and Authority Approvals
D. Quality Management
E. Safety Management
F. Commissioning, Turnover, and Closeout
G. KPI and Performance Reporting
H. Sustainability, ESG, and Corporate Standards
I. Document Control and Information Management
J. Lessons Learned
K. Templates and Logs

## 1. Document Control

### Purpose

This section establishes the official project record for the Project Execution Plan, identifies document ownership, tracks version history, and defines how updates will be reviewed and approved.

### Template Language

This Project Execution Plan is maintained by [Project Manager] on behalf of [Company / Business Unit]. It establishes the owner-side governance, controls, communication structure, and management approach for the [Project Name] project. The plan will be reviewed and updated at key project milestones, governance reviews, and material scope, budget, schedule, risk, or change-control events. The current approved version is [Version] dated [Date].

### Key Inputs

- Project name
- Document owner
- Version number and date
- Prepared by, reviewed by, and approved by
- Approval status
- Revision history
- Distribution list
- Storage location / system of record

### Recommended Table / Checklist

| Version | Date | Prepared By | Reviewed By | Approved By | Status | Summary of Changes |
| --- | --- | --- | --- | --- | --- | --- |
| 0.1 | [Insert date] | [Name] | [Name] | [Name] | Draft | Initial draft |
| 1.0 | [Insert date] | [Name] | [Name] | [Name] | Approved | Approved baseline |

Checklist:

- [ ] Document owner identified
- [ ] Current version and approval status documented
- [ ] Reviewers and approvers identified
- [ ] System of record identified
- [ ] Distribution list confirmed
- [ ] Update triggers defined

### Owner-Side Guidance

The Project Execution Plan should remain a controlled document. Updates should be made when project assumptions, scope, budget, schedule, governance, delivery strategy, or risk profile materially change. The owner-side project manager should confirm that the current approved version is available to the project sponsor, project team, and relevant stakeholders.

### REWS.AI Customization Note

A customized version may adapt document control fields to company standards, approval workflows, document repositories, project stage gates, and internal governance terminology.

## 2. Project Summary

### Purpose

This section provides a concise executive-ready summary of the project, business need, sponsor, location, phase, intended facility use, target dates, and delivery context.

### Template Language

The [Project Name] project is an owner-side corporate real estate capital project located at [Location]. The project is sponsored by [Project Sponsor] and managed by [Project Manager]. The project supports [business objective] and is intended to deliver [summary of project outcome]. The project is currently in [Phase] with a target completion, occupancy, operational readiness, production, or go-live date of [Date].

### Key Inputs

- Project name
- Location
- Project sponsor
- Project manager
- Business function supported
- Project type
- Intended facility use
- Current phase
- Target completion date
- Occupancy / operational readiness date
- Approved budget
- Delivery method
- Primary stakeholders

### Recommended Table / Checklist

| Field | Project Information |
| --- | --- |
| Project Name | [Insert] |
| Location | [Insert] |
| Project Sponsor | [Insert] |
| Project Manager | [Insert] |
| Business Function Supported | [Insert] |
| Project Type | [Insert] |
| Primary Intended Facility Use | [Insert] |
| Current Phase | [Insert] |
| Target Completion Date | [Insert] |
| Occupancy / Operational Readiness Requirement | [Insert] |
| Approved Budget | [Insert] |
| Delivery Method | [Insert] |
| Primary Stakeholders | [Insert] |

Checklist:

- [ ] Project sponsor confirmed
- [ ] Project manager confirmed
- [ ] Business objective summarized
- [ ] Intended facility use confirmed
- [ ] Target dates documented
- [ ] Budget baseline referenced
- [ ] Current phase identified

### Owner-Side Guidance

The project summary should be clear enough for executives and stakeholders who may not read the full Project Execution Plan. It should connect the project to the approved business need and provide enough context to understand scope, timing, governance, and project status.

### REWS.AI Customization Note

A customized version may adapt the project summary using project intake information, location, project type, business objectives, portfolio context, and the intended executive audience.

## 3. Project Classification

### Purpose

This section classifies the project so the owner-side project manager can scale governance, controls, stakeholder engagement, risk management, reporting, commissioning, turnover, and customization requirements appropriately.

### Template Language

The project classification should be completed early in the project lifecycle and revisited if the project scope, intended facility use, business function, operating model, regulatory environment, delivery method, or stakeholder requirements materially change. The classification is used to determine the appropriate controls level, governance model, reporting cadence, required appendices, and customization requirements.

### Key Inputs

- Project type
- Intended facility use
- Business function supported
- Operational criticality
- Compliance sensitivity
- Stakeholder complexity
- Technical complexity
- Delivery complexity
- Site / existing conditions
- Utility / infrastructure requirements
- Commissioning / turnover requirements
- Geographic or local market factors

### Recommended Table / Checklist

| Classification Field | Project-Specific Entry |
| --- | --- |
| Project Type | [Industrial / Commercial / Office / R&D / Lab / Manufacturing / Warehouse / Logistics / Data Center / Mixed-Use / Campus / Tenant Improvement / Build-to-Suit / Major Capital Improvement / Other] |
| Primary Intended Facility Use | [Administrative office / Sales / Marketing / Customer training / Medical device manufacturing / General manufacturing / Warehouse / Logistics / Data center / Wet labs / Electrical engineering labs / Mechanical engineering labs / R&D / Cleanroom / Clinical / Service center / Other] |
| Secondary or Supporting Uses | [Insert supporting uses such as office, lab, warehouse, amenity, utility, parking, training, customer experience, service, or other functions.] |
| Business Function Supported | [Insert business function, department, operating group, or user group.] |
| Operational Criticality | [Low / Medium / High / Business-critical] |
| Regulatory / Compliance Sensitivity | [Low / Medium / High - describe code, safety, environmental, quality, regulated industry, or operational compliance considerations.] |
| Stakeholder Complexity | [Low / Medium / High - describe affected business groups, executives, end users, operations, external parties, or community stakeholders.] |
| Technical Complexity | [Low / Medium / High - describe design, engineering, specialty equipment, utilities, infrastructure, or commissioning requirements.] |
| Delivery Complexity | [Low / Medium / High - describe delivery method, contract interfaces, procurement constraints, landlord/developer interfaces, long-lead items, or owner-direct packages.] |
| Site / Existing Conditions Complexity | [Low / Medium / High - describe existing site, building, utilities, access, operational constraints, or unknown conditions.] |
| Utility / Infrastructure Complexity | [Low / Medium / High - describe utility capacity, infrastructure, shutdown, service, or connection requirements.] |
| Commissioning / Turnover Complexity | [Low / Medium / High - describe systems, training, acceptance, commissioning, qualification, or operational readiness needs.] |
| Geographic / Local Market Complexity | [Low / Medium / High - describe local market, jurisdiction, labor, permitting, language, vendor, or regional factors.] |
| Recommended Controls Level | [Level 1 / Level 2 / Level 3] |
| Required Optional Appendices | [List applicable appendices.] |

Checklist:

- [ ] Project type confirmed
- [ ] Intended facility use confirmed
- [ ] Business function supported documented
- [ ] Operational criticality reviewed
- [ ] Compliance sensitivity assessed
- [ ] Technical and delivery complexity assessed
- [ ] Required appendices identified
- [ ] Classification reviewed with project sponsor

### Owner-Side Guidance

Project classification should influence how much governance, documentation, reporting, and control structure the project needs. Office projects may require lighter controls unless stakeholder or business-readiness risk is high. Lab, manufacturing, data center, regulated, or business-critical projects often require stronger controls, more formal governance, deeper commissioning, and more detailed turnover planning.

### REWS.AI Customization Note

A customized version may adapt this classification table based on project type, intended facility use, business criticality, technical complexity, delivery method, and location-specific requirements.

## 4. Project Complexity and Controls Level

### Purpose

This section determines the appropriate level of governance, reporting, documentation, controls, and optional appendices for the project.

### Template Language

The project has been classified as [Level 1 / Level 2 / Level 3]. The selected controls level reflects the project's size, complexity, business impact, stakeholder impact, delivery risk, budget exposure, schedule sensitivity, regulatory requirements, and operational consequences. The project team will apply governance, reporting, approval, risk, change, and documentation controls consistent with this classification.

### Key Inputs

- Project classification
- Budget range
- Schedule sensitivity
- Business impact
- Stakeholder impact
- Delivery method
- Regulatory or compliance sensitivity
- Operational readiness requirements
- Governance requirements
- Reporting requirements

### Recommended Table / Checklist

| Complexity Level | Definition | Typical Project Types | Recommended Governance | Recommended Reporting | Recommended Appendices |
| --- | --- | --- | --- | --- | --- |
| Level 1: Small / Low Complexity | Lower-risk project with limited stakeholder impact, limited technical complexity, and manageable budget / schedule exposure. | Small tenant improvement, minor workplace refresh, small capital improvement, single-location low-impact project. | Project Manager and Project Sponsor; executive approver only if needed. | Lightweight status updates, basic budget and schedule tracking, simple issue escalation. | Core sections only; appendices only if required by company policy or local conditions. |
| Level 2: Medium / Moderate Complexity | Moderate-risk project with multiple stakeholders, material business impact, defined approval needs, or meaningful cost / schedule exposure. | Office buildout, lab renovation, multi-stakeholder workplace project, moderate manufacturing or logistics improvement. | Project Manager, Project Sponsor, functional stakeholders, finance / procurement review as needed. | Formal budget and schedule reporting, monthly sponsor reporting, active risk and change tracking. | Selected appendices based on procurement, design, permitting, quality, safety, or closeout needs. |
| Level 3: Large / High Complexity | High-risk or business-critical project with significant cost, schedule, operational, regulatory, stakeholder, or reputational exposure. | Major campus project, new manufacturing facility, R&D building, build-to-suit, multi-region program, business-critical capital project. | Tiered governance with Project Working Team, Project Leadership Team, and Executive Steering Committee. | Formal cost, schedule, risk, change, quality, safety, and executive reporting controls. | Most appendices, including procurement, design, permitting, quality, safety, ESG, KPIs, commissioning, turnover, and closeout. |

Controls decision table:

| Controls Decision | Selected Approach | Notes |
| --- | --- | --- |
| Complexity Level | [Level 1 / Level 2 / Level 3] | [Basis for classification] |
| Governance Model | [Small / Medium / Large-Complex] | [Notes] |
| Reporting Intensity | [Lightweight / Formal monthly / Formal executive controls] | [Notes] |
| Required Appendices | [List appendices] | [Notes] |
| Executive Oversight | [None / Sponsor reporting / Steering committee] | [Notes] |

Checklist:

- [ ] Complexity level selected
- [ ] Controls level reviewed with sponsor
- [ ] Required appendices selected
- [ ] Reporting intensity defined
- [ ] Executive oversight requirements documented
- [ ] Complexity level will be revisited if scope or risk changes

### Owner-Side Guidance

The controls model should provide enough oversight without creating unnecessary administrative burden. Smaller projects should remain practical and lightweight, while larger or higher-risk projects should use more formal reporting, governance, risk, change, cost, schedule, quality, safety, and closeout controls.

### REWS.AI Customization Note

The customized version can recommend the appropriate controls level based on project size, project type, budget, schedule sensitivity, business impact, delivery method, location, stakeholder complexity, regulatory environment, and company governance requirements.

## 5. Business Objectives and Success Criteria

### Purpose

This section connects the project to the business need, strategic objective, operating requirement, stakeholder outcome, or capital approval basis that justifies the project.

### Template Language

The project has been authorized to support defined business objectives and operating requirements. The project team will manage scope, budget, schedule, risk, stakeholder alignment, and delivery decisions in a manner that supports the approved business case and success criteria. Changes that materially affect the business objective, approved budget, target schedule, operating readiness, stakeholder commitments, or expected benefits will be reviewed through the project governance and change-control process.

### Key Inputs

- Approved business case or capital request
- Project sponsor objectives
- Business function supported
- Intended facility use
- Operating requirements
- Stakeholder requirements
- Approved budget
- Target schedule or occupancy date
- Business readiness requirements
- Financial or operational drivers
- Strategic priorities
- Constraints and tradeoffs
- Owner acceptance criteria

### Recommended Table / Checklist

Business alignment table:

| Business Objective | Success Criteria | Measurement Method | Owner | Target Date / Milestone | Impact if Not Achieved |
| --- | --- | --- | --- | --- | --- |
| Support headcount growth | [Insert criteria] | [Insert measurement] | [Insert owner] | [Insert date] | [Insert impact] |
| Enable manufacturing or operational capacity | [Insert criteria] | [Insert measurement] | [Insert owner] | [Insert date] | [Insert impact] |
| Improve workplace effectiveness | [Insert criteria] | [Insert measurement] | [Insert owner] | [Insert date] | [Insert impact] |
| Meet regulatory or compliance requirements | [Insert criteria] | [Insert measurement] | [Insert owner] | [Insert date] | [Insert impact] |

Tradeoff table:

| Tradeoff Area | Priority | Decision Guidance | Escalation Required? |
| --- | --- | --- | --- |
| Cost certainty | [High / Medium / Low] | [Insert guidance] | [Yes / No] |
| Schedule certainty | [High / Medium / Low] | [Insert guidance] | [Yes / No] |
| Scope completeness | [High / Medium / Low] | [Insert guidance] | [Yes / No] |
| Quality / performance | [High / Medium / Low] | [Insert guidance] | [Yes / No] |
| Business continuity | [High / Medium / Low] | [Insert guidance] | [Yes / No] |
| Operational readiness | [High / Medium / Low] | [Insert guidance] | [Yes / No] |

Owner acceptance criteria:

| Acceptance Area | Acceptance Criteria | Evidence Required | Owner / Approver | Target Date |
| --- | --- | --- | --- | --- |
| Scope completion | [Insert criteria] | [Insert evidence] | [Insert approver] | [Insert date] |
| Operational readiness | [Insert criteria] | [Insert evidence] | [Insert approver] | [Insert date] |
| Turnover documentation | [Insert criteria] | [Insert evidence] | [Insert approver] | [Insert date] |

Checklist:

- [ ] Business objective documented
- [ ] Project sponsor alignment confirmed
- [ ] Success criteria defined
- [ ] Measurable outcomes identified where possible
- [ ] Key constraints documented
- [ ] Tradeoffs documented
- [ ] Acceptance criteria defined
- [ ] Material changes tied back to the business case

### Owner-Side Guidance

A project can be delivered on time and on budget but still fail if it does not meet the business need. Success criteria should include measurable business, operational, stakeholder, and readiness outcomes where possible. Tradeoffs should be explicit because decisions about cost, schedule, scope, quality, and readiness often compete.

### REWS.AI Customization Note

This section can be tailored to the company's capital approval process, business case format, project type, intended facility use, operating model, success metrics, financial drivers, stakeholder commitments, acceptance criteria, and executive reporting requirements.

## 6. Scope of Work

### Purpose

This section establishes the approved scope baseline and clarifies what is included, excluded, assumed, constrained, interfaced with other workstreams, and subject to change control.

### Template Language

The project scope baseline defines the work authorized for planning, design, procurement, construction, commissioning, turnover, and closeout. The scope baseline includes the approved project requirements, intended facility use, major deliverables, owner responsibilities, delivery partner responsibilities, assumptions, constraints, exclusions, and known interfaces. Potential changes to the scope baseline will be reviewed through the project change-control process before approval or implementation.

### Key Inputs

- Business requirements
- Project type
- Intended facility use
- Approved project objectives
- Basis of design or design brief
- Space program
- Site information
- Existing conditions
- Operational requirements
- Stakeholder requirements
- Regulatory requirements
- Corporate standards
- Budget baseline
- Schedule baseline
- Delivery method
- Contract structure
- Owner responsibilities
- Vendor / consultant responsibilities

### Recommended Table / Checklist

Scope baseline table:

| Scope Element | Included in Scope? | Description | Owner / Responsible Party | Key Assumptions | Key Constraints | Change-Control Trigger |
| --- | --- | --- | --- | --- | --- | --- |
| Site / building acquisition or lease interface | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Due diligence | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Design and engineering | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Permitting and approvals | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Procurement | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Construction / fit-out | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Furniture, fixtures, and equipment | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| IT / AV / security | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Utilities and infrastructure | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Specialty equipment | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Commissioning and qualification | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Move / occupancy / operational readiness | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Closeout and turnover | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Inclusions / exclusions table:

| Item | Included / Excluded | Rationale | Notes |
| --- | --- | --- | --- |
| [Insert item] | [Included / Excluded] | [Insert rationale] | [Insert notes] |

Assumptions / constraints table:

| Assumption or Constraint | Impact if Incorrect or Changed | Owner | Validation Date | Status |
| --- | --- | --- | --- | --- |
| [Insert assumption / constraint] | [Insert impact] | [Insert owner] | [Insert date] | [Open / Validated / Changed] |

Interfaces table:

| Interface | Related Party / Workstream | Coordination Requirement | Risk if Not Managed | Owner |
| --- | --- | --- | --- | --- |
| [Insert interface] | [Insert party / workstream] | [Insert requirement] | [Insert risk] | [Insert owner] |

Change-control triggers:

- New stakeholder requirement
- Change in intended facility use
- Change in project type or operating model
- Change in code, permit, or authority requirement
- Change in corporate standard
- Change in equipment, utilities, or infrastructure requirements
- Change in occupancy or operational readiness date
- Addition or removal of project area
- Budget or schedule impact
- Contract scope gap or overlap
- Field condition or existing condition issue

Checklist:

- [ ] Scope baseline documented
- [ ] Inclusions documented
- [ ] Exclusions documented
- [ ] Assumptions documented
- [ ] Constraints documented
- [ ] Interfaces documented
- [ ] Owner responsibilities clarified
- [ ] Delivery partner responsibilities clarified
- [ ] Scope baseline reviewed with stakeholders
- [ ] Change-control triggers defined

### Owner-Side Guidance

The scope section should establish the owner's approved scope baseline. Scope should be clear enough to support budget, schedule, procurement, design, stakeholder alignment, and change control. Ambiguous exclusions, assumptions, and interfaces are common sources of change orders, delays, stakeholder dissatisfaction, and budget growth.

### REWS.AI Customization Note

For project-specific use, this section should be aligned with project type, intended facility use, operating model, location, code requirements, corporate standards, contract form, delivery method, space program, utility requirements, commissioning requirements, and stakeholder approval process.

## 7. Project Delivery Strategy

### Purpose

This section documents the selected delivery method, procurement approach, owner responsibilities, risk allocation, governance model, and decision-making process.

### Template Language

The project will be delivered using [Insert delivery method]. The selected delivery method has been chosen based on project complexity, schedule requirements, cost certainty, procurement constraints, design maturity, market conditions, owner governance needs, and risk allocation. The owner will govern scope, budget, schedule, quality, risk, stakeholder decisions, approvals, and vendor performance in accordance with this Project Execution Plan and applicable company requirements.

### Key Inputs

- Selected delivery method
- Rationale for delivery method
- Procurement constraints
- Design maturity
- Cost certainty requirements
- Schedule requirements
- Contract structure
- Owner responsibilities
- Vendor / consultant responsibilities
- Risk allocation
- Approval requirements

### Recommended Table / Checklist

Delivery method options:

- Design-Bid-Build
- Design-Build
- CM-at-Risk / GC GMP
- Construction Management as Agent
- Landlord-delivered tenant improvement
- Developer-led build-to-suit
- Owner-direct vendor packages
- Other / hybrid delivery models

Delivery strategy table:

| Field | Project-Specific Entry |
| --- | --- |
| Selected Delivery Method | [Insert delivery method] |
| Rationale for Selected Delivery Method | [Explain why selected based on complexity, schedule, cost certainty, procurement constraints, design maturity, market conditions, and owner governance needs.] |
| Owner's Role | [Describe how the owner will govern scope, budget, schedule, quality, risk, stakeholder decisions, approvals, and vendor performance.] |
| Contract Structure | [Insert contract structure] |
| Procurement Approach | [Insert procurement approach] |
| Key Delivery Risks | [Identify risks related to design completion, procurement timing, cost certainty, schedule certainty, change control, stakeholder approvals, contract interfaces, and vendor performance.] |

Checklist:

- [ ] Delivery method selected
- [ ] Rationale documented
- [ ] Owner responsibilities documented
- [ ] Contract structure documented
- [ ] Procurement approach aligned with schedule
- [ ] Key delivery risks identified
- [ ] Contract interfaces reviewed
- [ ] Decision and approval process aligned with delivery strategy

### Owner-Side Guidance

The Project Execution Plan should define the owner-side delivery strategy, not contractor means and methods. The owner should focus on governance, decision timing, procurement alignment, contract interfaces, risk allocation, cost and schedule visibility, stakeholder decisions, and approval requirements.

### REWS.AI Customization Note

A customized version may adapt this section for the selected delivery method, contract structure, procurement strategy, owner approval model, regional procurement norms, local contract forms, and project-specific risk allocation.

## 8. Governance and Decision-Making

### Purpose

This section defines how project decisions will be made, approved, escalated, documented, and communicated.

### Template Language

The project will be managed through a defined governance model that establishes decision rights, approval requirements, escalation thresholds, meeting cadence, and executive reporting expectations. Decisions affecting approved scope, budget, schedule, contingency, business readiness, risk exposure, procurement awards, or material stakeholder commitments will be reviewed and approved in accordance with the project governance model and approval authority matrix.

### Key Inputs

- Project complexity level
- Project sponsor
- Project manager
- Approval authority matrix
- Capital governance process
- Decision rights
- Escalation thresholds
- Steering committee requirements
- Reporting cadence
- Change approval thresholds
- Contingency approval rules

### Recommended Table / Checklist

Governance model options:

| Governance Model | Typical Roles | Best For |
| --- | --- | --- |
| Small Project Governance | Project Manager, Project Sponsor, Executive Approver only if needed | Smaller tenant improvements, minor capital upgrades, and low-risk projects |
| Medium Project Governance | Project Manager, Project Sponsor, Functional Stakeholders, Finance / Procurement review as needed | Moderate-risk capital projects with multiple internal stakeholders |
| Large / Complex Project Governance | Project Working Team, Project Leadership Team, Executive Steering Committee | Major capital projects, campus projects, labs, manufacturing, logistics, or business-critical projects |

Default large / complex tiered governance example:

| Tier | Governance Forum | Primary Role |
| --- | --- | --- |
| Tier 1 | Project Working Team | Handles day-to-day coordination, action items, issue tracking, document control, vendor follow-up, meeting cadence, and near-term execution. |
| Tier 2 | Project Leadership Team | Handles scope alignment, budget tracking, schedule performance, risk escalation, procurement recommendations, change review, stakeholder alignment, and decision preparation. |
| Tier 3 | Executive Steering Committee | Handles major business decisions, funding approvals, material scope changes, significant schedule impacts, contingency usage above threshold, unresolved escalations, and business-readiness decisions. |

Sample approval matrix:

| Decision Type | Project Manager | Project Sponsor | Functional Stakeholder | Finance / Procurement | Real Estate / Capital Projects Leader | Executive Steering Committee |
| --- | --- | --- | --- | --- | --- | --- |
| Minor scope clarification | Recommend | Approve | Consult | Inform | Inform | Inform |
| Budget transfer within approved project budget | Recommend | Review | Inform | Review | Approve | Inform |
| Use of contingency above threshold | Recommend | Review | Consult | Review | Recommend | Approve |
| Major scope change | Recommend | Recommend | Consult | Review | Recommend | Approve |
| Schedule change affecting business opening date | Recommend | Recommend | Consult | Review | Recommend | Approve |
| Procurement award recommendation | Recommend | Review | Consult | Review | Approve | Inform / Approve if threshold exceeded |
| Project budget increase | Recommend | Recommend | Consult | Review | Recommend | Approve |
| Final project closeout acceptance | Recommend | Approve | Consult | Review | Review | Inform |

Editable governance language:

- The governance structure for this project is: [Small / Medium / Large-Complex]
- The project decision-making model is: [Describe the working team, leadership team, executive approval process, escalation path, and decision cadence.]
- Decisions requiring escalation include: [List decisions that exceed the project manager's authority.]

Checklist:

- [ ] Governance model selected
- [ ] Decision rights documented
- [ ] Approval matrix reviewed
- [ ] Escalation thresholds defined
- [ ] Steering committee requirements confirmed
- [ ] Contingency approval process documented
- [ ] Executive reporting cadence defined

### Owner-Side Guidance

Clear governance reduces delayed decisions, informal approvals, unclear accountability, and unmanaged scope, budget, or schedule impacts. Governance should be scaled to project complexity and should define who recommends, reviews, approves, is consulted, and is informed.

### REWS.AI Customization Note

This section can be tailored to align with the company's approval authority matrix, steering committee structure, escalation thresholds, capital governance process, and executive reporting cadence.

## 9. Roles and Responsibilities

### Purpose

This section defines the primary project roles, responsibilities, decision rights, coordination expectations, and accountability structure for the owner-side project team and key delivery partners.

### Template Language

The project will be managed through a defined role and responsibility structure that clarifies accountability for scope, budget, schedule, risk, stakeholder coordination, decision-making, approvals, communication, and delivery partner performance. Each project participant is expected to understand their role, decision authority, escalation path, and required contributions to project success.

### Key Inputs

- Project governance model
- Project sponsor
- Owner-side project manager
- Real estate / capital projects leader
- Functional stakeholders
- Finance partner
- Procurement partner
- Legal / risk / compliance partner
- Design team
- Contractor / construction manager
- Landlord / developer, if applicable
- Vendors and consultants
- Facilities / operations team
- End-user or business representative
- Approval authority matrix

### Recommended Table / Checklist

Role table:

| Role | Primary Responsibilities | Decision Authority | Key Deliverables | Escalation Path |
| --- | --- | --- | --- | --- |
| Project Sponsor | Owns business objective, funding alignment, key decisions, and executive escalation. | Approves sponsor-level decisions. | Sponsor direction, approvals, escalations. | Executive leadership / steering committee. |
| Owner-side Project Manager | Coordinates scope, budget, schedule, risks, decisions, stakeholders, vendors, and reporting. | Recommends decisions and approves within delegated authority. | PEP, status reports, logs, coordination outputs. | Project Sponsor / RE leader. |
| Real Estate / Capital Projects Leader | Provides portfolio, governance, delivery, and capital project oversight. | Approves or recommends within authority matrix. | Governance input, escalations, executive alignment. | Executive sponsor / steering committee. |
| Functional Stakeholder / Business Owner | Provides requirements, reviews decisions, supports readiness and adoption. | Consulted or approves functional requirements. | Requirements, feedback, readiness input. | Project Sponsor. |
| Finance Partner | Supports budget, forecast, accruals, funding, and financial controls. | Reviews / approves financial items within policy. | Cost review, accrual input, financial reporting. | Finance leadership. |
| Procurement Partner | Supports sourcing, award approvals, vendor onboarding, and procurement compliance. | Reviews / approves procurement steps within policy. | Procurement plan, award support, vendor records. | Procurement leadership. |
| Legal / Risk / Compliance Partner | Supports contract, risk, compliance, insurance, and regulatory review. | Reviews / advises within area of responsibility. | Legal / risk review input. | Legal / risk leadership. |
| Design Lead | Leads design deliverables, design coordination, and technical design recommendations. | Recommends design solutions within professional scope. | Design deliverables, review responses. | Owner PM / design leadership. |
| Contractor / Construction Manager | Supports delivery planning, construction execution, coordination, reporting, and closeout as contracted. | As defined by contract. | Delivery reports, submittals, RFIs, closeout deliverables. | Owner PM / contract escalation path. |
| Facilities / Operations Lead | Supports maintainability, operations readiness, handoff, and turnover. | Consulted / approves operational readiness items. | O&M input, turnover review, acceptance input. | Facilities / operations leadership. |
| End-User Representative | Provides user requirements, readiness input, and acceptance feedback. | Consulted on user-facing decisions. | User feedback, readiness input. | Functional stakeholder / sponsor. |

Basic RACI matrix:

| Activity | Sponsor | Owner PM | RE / Capital Leader | Finance / Procurement | Stakeholders | Delivery Partners |
| --- | --- | --- | --- | --- | --- | --- |
| Approve project objectives | A | R | C | C | C | I |
| Confirm scope baseline | A | R | C | C | C | C |
| Manage day-to-day project execution | I | A/R | C | C | I | R |
| Approve budget changes | A | R | C | C/R | I | C |
| Review schedule status | I | A/R | C | I | C | R |
| Approve major changes | A | R | C | C | C | C |
| Manage stakeholder communications | C | A/R | C | I | C | I |
| Review risk register | C | A/R | C | C | C | C |
| Approve procurement recommendations | C | R | A/C | R/C | C | I |
| Accept turnover / closeout | A | R | C | C | C | R |

RACI labels:

- R = Responsible
- A = Accountable
- C = Consulted
- I = Informed

Checklist:

- [ ] Project sponsor identified
- [ ] Owner-side project manager identified
- [ ] Key stakeholder groups identified
- [ ] Finance and procurement partners identified
- [ ] Design and delivery partner roles confirmed
- [ ] Decision authorities documented
- [ ] Escalation paths documented
- [ ] RACI reviewed with project leadership
- [ ] Turnover and operational ownership clarified

### Owner-Side Guidance

The PEP should clarify owner-side accountability, not replace company job descriptions. Delivery partners may manage day-to-day design or construction tasks under their contracts, but the owner remains accountable for business objectives, approvals, stakeholder alignment, and project governance.

### REWS.AI Customization Note

This section can be tailored to the company's organization structure, project governance model, approval authority matrix, delivery method, contract form, project phase, stakeholder groups, vendor structure, and internal department names.

## 10. Stakeholder Management

### Purpose

This section identifies the key stakeholders, stakeholder groups, engagement needs, decision roles, communication expectations, and escalation paths required to support project success.

### Template Language

The project team will maintain a stakeholder management approach that identifies key business, functional, operational, financial, procurement, legal, facilities, technology, security, and executive stakeholders. Stakeholders will be engaged at the appropriate cadence based on their role in project decisions, approvals, requirements, operational readiness, risk management, and business adoption.

### Key Inputs

- Stakeholder groups
- Sponsor and decision makers
- Business / functional users
- Facilities / operations
- IT / AV / security
- Finance and procurement
- Legal, risk, compliance
- EHS / safety
- Communications / change management
- Landlord / developer, if applicable
- External authorities, if applicable
- Engagement cadence
- Decision roles
- Escalation path

### Recommended Table / Checklist

Stakeholder table:

| Stakeholder / Group | Role in Project | Key Interests / Requirements | Engagement Method | Cadence | Decision Role | Escalation Path |
| --- | --- | --- | --- | --- | --- | --- |
| Project Sponsor | Business owner / approver | [Insert] | Sponsor meeting / report | [Insert] | Approve / escalate | [Insert] |
| Business Function | Requirements / readiness | [Insert] | Workshops / reviews | [Insert] | Consult / approve requirements | [Insert] |
| Facilities / Operations | Turnover / maintainability | [Insert] | Design reviews / readiness meetings | [Insert] | Consult / accept | [Insert] |
| Finance | Budget / forecast / accruals | [Insert] | Cost reviews | [Insert] | Review / approve | [Insert] |
| Procurement | Sourcing / awards / vendor controls | [Insert] | Procurement reviews | [Insert] | Review / approve | [Insert] |
| IT / AV / Security | Technology and security requirements | [Insert] | Coordination meetings | [Insert] | Consult / approve | [Insert] |
| EHS / Safety | Safety and compliance input | [Insert] | Safety reviews | [Insert] | Consult / approve where applicable | [Insert] |

Checklist:

- [ ] Stakeholder groups identified
- [ ] Decision makers identified
- [ ] Requirements owners identified
- [ ] Engagement cadence defined
- [ ] Escalation paths documented
- [ ] Operational readiness stakeholders included
- [ ] Stakeholder concerns and decisions tracked

### Owner-Side Guidance

Stakeholder management should focus on requirements, decisions, readiness, risks, and adoption. Stakeholder engagement should be structured and time-bound so project input is gathered without creating design churn, decision delays, or uncontrolled scope changes.

### REWS.AI Customization Note

This section can be tailored based on the company's organization structure, business units, project location, stakeholder groups, governance model, approval authority matrix, operational readiness requirements, security requirements, technology dependencies, workplace change impacts, and executive reporting cadence.

## 11. Communication and Reporting Plan

### Purpose

This section defines the communication cadence, meeting structure, reporting outputs, audiences, decision forums, escalation routes, and project information flow.

### Template Language

The project team will maintain a communication and reporting plan that provides timely, accurate, and audience-appropriate information to the project sponsor, project team, stakeholders, finance, procurement, delivery partners, and executive leadership. Project communications will support decision-making, risk escalation, budget and schedule visibility, stakeholder alignment, and business readiness.

### Key Inputs

- Project governance model
- Stakeholder groups
- Meeting cadence
- Reporting cadence
- Executive reporting needs
- Budget and schedule reporting inputs
- Risk and change reporting inputs
- Decision and escalation requirements
- Confidentiality or information controls
- Communication channels

### Recommended Table / Checklist

Communication matrix:

| Communication / Forum | Audience | Purpose | Frequency | Owner | Required Inputs | Output / Decision Needed |
| --- | --- | --- | --- | --- | --- | --- |
| Weekly project team meeting | Project team / delivery partners | Coordinate near-term actions, risks, and issues | Weekly | Owner PM | Action log, schedule, open issues | Updated action log |
| Sponsor update | Sponsor / RE leader | Review project health, decisions, and escalations | Biweekly / Monthly | Owner PM | Status report, risks, budget, schedule | Decisions / direction |
| Cost and schedule review | Owner PM, finance, project controls | Review budget, forecast, commitments, and milestones | Monthly | Owner PM / Finance | Cost report, schedule tracker | Cost / schedule actions |
| Risk and change review | Project leadership | Review risks, changes, decisions, and escalation items | Monthly or as needed | Owner PM | Risk register, change log, decision log | Approvals / escalations |
| Executive reporting snapshot | Sponsor / leadership | Provide concise view of project health and required actions | Monthly or governance cadence | Owner PM | RAG status, budget, schedule, risks | Executive action |
| Turnover readiness review | Facilities, operations, IT, security, stakeholders | Confirm readiness for occupancy / operations | As needed near turnover | Owner PM | Turnover tracker, closeout tracker | Readiness actions |

Reporting cadence table:

| Report | Audience | Frequency | Owner | Distribution Method |
| --- | --- | --- | --- | --- |
| Project status report | [Insert] | [Insert] | [Insert] | [Insert] |
| Executive snapshot | [Insert] | [Insert] | [Insert] | [Insert] |
| Cost report | [Insert] | [Insert] | [Insert] | [Insert] |
| Schedule milestone report | [Insert] | [Insert] | [Insert] | [Insert] |
| Risk / change report | [Insert] | [Insert] | [Insert] | [Insert] |

Checklist:

- [ ] Meeting cadence established
- [ ] Reporting cadence established
- [ ] Audiences confirmed
- [ ] Report owners assigned
- [ ] Required inputs identified
- [ ] Escalation process defined
- [ ] Executive reporting format confirmed
- [ ] Communication records stored in system of record

### Owner-Side Guidance

Communication should support decisions, accountability, and alignment. Reports should be concise, forward-looking, and clear about decisions needed, actions required, risks, budget status, schedule status, and escalation items.

### REWS.AI Customization Note

For project-specific use, this section should be aligned with stakeholder groups, reporting cadence, meeting structure, executive dashboard fields, RAG definitions, escalation thresholds, communication channels, business readiness requirements, approval authority matrix, confidentiality rules, and internal communication standards.

## 12. Budget and Cost Management

### Purpose

This section establishes how the owner-side project team will manage the approved budget, commitments, actual costs, forecast, contingency, change orders, invoices, accruals, and cost-related escalations.

### Template Language

The project team will manage the project against the approved budget baseline. Cost performance will be reviewed at the agreed reporting cadence and will include budget, commitments, actual costs, forecast-to-complete, forecast-at-completion, contingency status, pending changes, approved changes, invoice status, and cost risks. Material cost variances, contingency usage, and budget impacts will be escalated in accordance with the project governance and approval authority matrix.

### Key Inputs

- Approved project budget
- Budget breakdown / cost categories
- Contract values and commitments
- Actual costs
- Forecast-to-complete
- Forecast-at-completion
- Contingency amount and usage rules
- Pending and approved change orders
- Invoice status
- Accrual requirements
- Escalation thresholds

### Recommended Table / Checklist

Cost management table:

| Cost Category | Approved Budget | Committed Cost | Actual Cost | Forecast-to-Complete | Forecast-at-Completion | Variance | Notes / Action Required |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Design / consultants | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Construction / fit-out | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| FF&E | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| IT / AV / security | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Owner-direct vendors | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Contingency | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Contingency table:

| Contingency Item | Amount | Status | Approval Required | Approved By | Notes |
| --- | --- | --- | --- | --- | --- |
| [Insert item] | [Insert] | [Pending / Approved / Rejected] | [Yes / No] | [Insert] | [Insert] |

Checklist:

- [ ] Approved budget baseline confirmed
- [ ] Cost categories established
- [ ] Commitments tracked
- [ ] Actual costs tracked
- [ ] Forecast-to-complete updated
- [ ] Forecast-at-completion updated
- [ ] Contingency usage rules defined
- [ ] Change orders logged
- [ ] Invoices reviewed against contract terms and completed work
- [ ] Accruals coordinated with finance
- [ ] Budget risks escalated according to governance thresholds

### Owner-Side Guidance

The PEP should define the cost-control framework, not replace a full cost report. Forecasting should be forward-looking, not merely a record of actual costs. Contingency should have defined usage rules and approval thresholds. Accruals should be coordinated with finance based on work performed but not yet invoiced.

### REWS.AI Customization Note

For project-specific use, this section should be aligned with the company's budget categories, currency, cost codes, contingency rules, invoice workflow, accrual process, finance reporting requirements, and project controls tools.

## 13. Schedule Management

### Purpose

This section establishes how the owner-side project team will manage the approved schedule, milestones, critical activities, dependencies, schedule updates, recovery actions, stakeholder commitments, and schedule-related escalations.

### Template Language

The project team will manage the project against the approved baseline schedule. Schedule performance will be reviewed at the agreed reporting cadence and will include milestone status, critical path activities, near-term look-ahead activities, key dependencies, schedule risks, delayed activities, recovery actions, and decisions required to maintain or recover the approved project timeline. Material schedule impacts will be escalated in accordance with the project governance model and approval authority matrix.

### Key Inputs

- Approved baseline schedule
- Target completion date
- Business occupancy or operational readiness date
- Major project milestones
- Critical path activities
- Design deliverable dates
- Procurement and long-lead items
- Permit and authority approval dates
- Construction milestones
- Commissioning and turnover milestones
- Owner decision dates
- Stakeholder dependency dates
- Schedule update cadence
- Recovery action requirements
- Escalation thresholds

### Recommended Table / Checklist

Milestone tracker:

| Milestone | Baseline Date | Current Forecast Date | Variance | Status | Owner / Responsible Party | Action Required |
| --- | --- | --- | --- | --- | --- | --- |
| Business requirements complete | [Insert] | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |
| Design approval | [Insert] | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |
| Permit approval | [Insert] | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |
| Construction start | [Insert] | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |
| Substantial completion | [Insert] | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |
| Occupancy / operational readiness | [Insert] | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |
| Closeout complete | [Insert] | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |

Look-ahead planning table:

| Look-Ahead Activity | Required By | Owner | Dependency | Risk if Delayed | Action Required |
| --- | --- | --- | --- | --- | --- |
| [Insert activity] | [Insert date] | [Insert owner] | [Insert dependency] | [Insert risk] | [Insert action] |

Checklist:

- [ ] Baseline schedule approved
- [ ] Major milestones identified
- [ ] Critical path reviewed
- [ ] Long-lead items tracked
- [ ] Owner decision dates documented
- [ ] Permitting and authority approval dates included
- [ ] Stakeholder dependencies identified
- [ ] Schedule update cadence established
- [ ] Look-ahead planning process defined
- [ ] Recovery actions documented when needed
- [ ] Schedule impacts escalated according to governance thresholds

### Owner-Side Guidance

The PEP should define the schedule-control framework, not replace the detailed project schedule. The project manager should focus on milestone control, critical path awareness, decision timing, procurement risks, permitting dependencies, stakeholder readiness, and business impacts.

### REWS.AI Customization Note

This section can be tailored to the project type, delivery method, milestone structure, reporting cadence, business readiness date, owner decision process, permitting timeline, long-lead procurement strategy, schedule software, stakeholder dependencies, and escalation thresholds.

## 14. Risk and Change Management

### Purpose

This section establishes how the owner-side project team will identify, evaluate, manage, escalate, and report project risks and changes.

### Template Language

The project team will maintain an active risk and change management process throughout the project lifecycle. Risks will be identified, assigned to owners, evaluated for potential impact, and managed through mitigation actions. Potential changes will be reviewed for scope, budget, schedule, operational, stakeholder, regulatory, and business impacts before approval. Material risks and changes will be escalated in accordance with the project governance model, approval authority matrix, and reporting cadence.

### Key Inputs

- Approved scope baseline
- Approved budget baseline
- Approved schedule baseline
- Risk register
- Change log
- Decision log
- Issue log
- Contract change provisions
- Stakeholder requirements
- Design changes
- Field conditions
- Authority requirements
- Business or operational changes
- Contingency rules
- Approval thresholds
- Escalation requirements

### Recommended Table / Checklist

Risk table:

| Risk ID | Risk Description | Potential Impact | Probability | Severity | Risk Owner | Mitigation Action | Status | Escalation Required |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R-001 | [Insert risk] | [Scope / Budget / Schedule / Quality / Business / Compliance] | [Low / Medium / High] | [Low / Medium / High] | [Insert owner] | [Insert action] | [Open / Monitoring / Closed] | [Yes / No] |

Change table:

| Change ID | Change Description | Source / Requestor | Scope Impact | Budget Impact | Schedule Impact | Recommendation | Approval Required | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| C-001 | [Insert change] | [Insert source] | [Insert impact] | [Insert impact] | [Insert impact] | [Approve / Reject / Defer / Study] | [Insert approver] | [Pending / Approved / Rejected / Deferred] |

Decision log:

| Decision ID | Decision Needed | Decision Owner | Due Date | Impact if Delayed | Status | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| D-001 | [Insert decision] | [Insert owner] | [Insert date] | [Insert impact] | [Open / Decided / Escalated] | [Insert notes] |

Checklist:

- [ ] Risk register established
- [ ] Risk owners assigned
- [ ] Mitigation actions documented
- [ ] High-priority risks reviewed at agreed cadence
- [ ] Change intake process defined
- [ ] Scope, budget, and schedule impacts reviewed before approval
- [ ] Change approval thresholds defined
- [ ] Contingency use linked to approved changes
- [ ] Decision log maintained
- [ ] Material risks and changes escalated according to governance thresholds
- [ ] Approved changes incorporated into budget, schedule, and scope baselines
- [ ] Rejected or deferred changes documented

### Owner-Side Guidance

Risk management should be proactive and forward-looking. Change management should protect the approved scope, budget, schedule, and business objectives. Risks, issues, changes, and decisions should be coordinated because they often affect each other. Decision delays can become project risks and should be tracked.

For more detailed project controls, use separate Risk Register, Change Management Procedure, and Decision Log templates as companion tools.

### REWS.AI Customization Note

This section can be tailored to the company's risk categories, change approval thresholds, contingency rules, contract form, delivery method, authority matrix, issue escalation process, risk scoring method, reporting cadence, and decision governance model.

## 15. Executive Summary and Reporting Snapshot

### Purpose

This section provides a concise executive-level summary of project status, key decisions, risks, budget, schedule, and next steps.

### Template Language

The project team will maintain a concise executive reporting snapshot to communicate overall project health, current status, key risks, upcoming decisions, budget position, schedule position, and required leadership actions. This snapshot should be updated at the agreed reporting cadence and used to support sponsor updates, leadership reviews, and escalation discussions.

### Key Inputs

- Overall project status
- Budget status
- Schedule status
- Scope / change status
- Key risks and issues
- Open decisions
- Upcoming milestones
- Change requests
- Required executive actions
- Reporting period

### Recommended Table / Checklist

RAG status definitions:

| Status | Definition |
| --- | --- |
| Green | Project is generally tracking to approved scope, budget, schedule, and risk expectations. |
| Yellow | Project has issues or risks that require active management but can likely be resolved within existing governance, contingency, or schedule float. |
| Red | Project has material issues affecting approved scope, budget, schedule, business readiness, regulatory compliance, or executive commitments and requires escalation. |

Executive reporting snapshot:

| Reporting Period | Overall Status | Budget Status | Schedule Status | Scope / Change Status | Top 3 Risks or Issues | Key Decisions Needed | Upcoming Milestones | Executive Action Required |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Insert period] | [Green / Yellow / Red] | [Green / Yellow / Red] | [Green / Yellow / Red] | [Green / Yellow / Red] | [Insert] | [Insert] | [Insert] | [Insert] |

Executive action checklist:

- [ ] Overall project status updated
- [ ] Budget and forecast status updated
- [ ] Schedule and milestone status updated
- [ ] Top risks and issues summarized
- [ ] Key decisions needed identified
- [ ] Upcoming milestones documented
- [ ] Executive actions clearly stated
- [ ] Escalations aligned with governance model

### Owner-Side Guidance

Executive reporting should be concise, factual, forward-looking, and action-oriented. It should help sponsors and leaders understand project health, required decisions, escalation items, and business readiness implications without needing to review the full project record.

For projects requiring formal executive governance, use a separate Steering Committee Report template as a companion reporting tool.

### REWS.AI Customization Note

A customized version may adapt executive reporting to the company's governance model, steering committee format, reporting cadence, project controls standards, RAG definitions, approval thresholds, budget categories, schedule milestones, and executive dashboard requirements.

## Optional Appendices

The following appendices may be included, removed, or marked "Not Applicable" based on project complexity, delivery strategy, location, risk profile, stakeholder needs, and company governance requirements.

## Appendix A: Procurement and Contracting Strategy

### Purpose

This appendix defines the owner-side strategy for selecting, contracting with, coordinating, and managing consultants, contractors, vendors, landlord/developer parties, and owner-direct suppliers required to deliver the project.

### Template Language

The project team will establish a procurement and contracting strategy that supports the approved scope, budget, schedule, delivery method, risk allocation, governance model, and business objectives. Procurement activities will be coordinated with finance, procurement, legal, stakeholders, and delivery partners to help confirm that vendor selection, award approvals, contract interfaces, long-lead items, and owner-direct packages are properly planned, approved, and managed.

### Key Inputs

- Project delivery method
- Approved scope baseline
- Approved budget
- Baseline schedule
- Procurement policies
- Contracting requirements
- Approval authority matrix
- Vendor qualification requirements
- Long-lead items
- Consultant requirements
- Contractor requirements
- Owner-direct vendor requirements
- Landlord or developer responsibilities, if applicable
- Local market conditions
- Insurance, risk, and compliance requirements
- Legal / procurement review requirements

### Recommended Tables / Checklists

Procurement strategy table:

| Package / Service | Procurement Method | Contracting Party | Target Award Date | Required Approvals | Long-Lead Risk | Interface Risk | Notes / Action Required |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Architect / design team | [Insert] | [Owner / Landlord / Developer / Other] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Engineering consultants | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Cost consultant / estimator | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| General contractor / construction manager | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Specialty consultants | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Permitting consultant | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Commissioning agent | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Furniture, fixtures, and equipment | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| IT / AV / security | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Specialty equipment | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Owner-direct vendors | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Landlord / developer work | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |
| Move / relocation services | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Low / Medium / High] | [Insert] |

Contract interface table:

| Interface | Responsible Party | Related Contract / Agreement | Coordination Requirement | Risk if Not Managed | Owner-Side Action |
| --- | --- | --- | --- | --- | --- |
| Owner and landlord work | [Insert] | [Lease / work letter / other] | [Insert] | Scope gaps, delays, acceptance issues | [Insert action] |
| Developer-delivered shell and owner fit-out | [Insert] | [Development agreement / lease / other] | [Insert] | Turnover delays, unclear readiness criteria | [Insert action] |
| Design team and contractor | [Insert] | [Design agreement / construction contract] | [Insert] | RFIs, rework, constructability issues | [Insert action] |
| Contractor and owner-direct vendors | [Insert] | [Construction contract / vendor agreements] | [Insert] | Access conflicts, schedule delays, warranty gaps | [Insert action] |
| IT / AV / security and construction | [Insert] | [Vendor agreements / construction contract] | [Insert] | Late infrastructure changes or missed rough-ins | [Insert action] |
| Equipment vendors and utilities | [Insert] | [Vendor agreement / utility agreement] | [Insert] | Utility capacity, service, or installation delays | [Insert action] |
| Commissioning agent and delivery partners | [Insert] | [Commissioning scope / delivery contracts] | [Insert] | Testing gaps, turnover delays | [Insert action] |
| Operations / facilities and closeout | [Insert] | [Closeout requirements] | [Insert] | Incomplete handoff or missing records | [Insert action] |
| Lease obligations and project delivery requirements | [Insert] | [Lease / work letter] | [Insert] | Noncompliance with lease obligations | [Insert action] |

Long-lead item tracker:

| Long-Lead Item | Required For | Procurement Owner | Required Decision Date | Target Order Date | Target Delivery Date | Risk / Mitigation |
| --- | --- | --- | --- | --- | --- | --- |
| [Insert item] | [Insert use] | [Insert owner] | [Insert date] | [Insert date] | [Insert date] | [Insert risk / mitigation] |

Procurement checklist:

- [ ] Procurement strategy aligned with delivery method
- [ ] Consultant and vendor requirements identified
- [ ] Long-lead items identified
- [ ] Owner-direct packages identified
- [ ] Landlord / developer responsibilities documented
- [ ] Contract interfaces identified
- [ ] Award approval process confirmed
- [ ] Procurement schedule aligned with project schedule
- [ ] Finance, procurement, and legal review requirements confirmed
- [ ] Insurance, compliance, and risk requirements confirmed
- [ ] Contract scope gaps and overlaps reviewed
- [ ] Vendor onboarding requirements identified
- [ ] Change-order and invoice requirements aligned with contract structure

### Owner-Side Guidance

The PEP should define the procurement and contracting approach at a planning level, not replace company procurement policy or legal review. Procurement strategy should be aligned with the project delivery method, schedule needs, market conditions, budget constraints, and risk allocation.

Owner-direct vendors can create interface risk if responsibilities, schedule access, coordination, insurance, and acceptance criteria are not clearly defined. Landlord-delivered work, developer-led work, build-to-suit obligations, and tenant improvement responsibilities should be mapped to the relevant lease, work letter, development agreement, or contract. Long-lead items should be identified early and tracked as schedule and risk items.

For projects with complex procurement, contract interfaces, or approval requirements, use a separate Procurement and Contracting Plan as a companion planning tool.

### REWS.AI Customization Note

This appendix can be tailored to the project delivery method, contract structure, procurement policy, approval authority matrix, local market, currency, vendor categories, landlord/developer obligations, owner-direct packages, insurance requirements, long-lead items, and contract interface risks.

## Appendix B: Design Management

### Purpose

This appendix defines how the owner-side project team will manage design requirements, design deliverables, review checkpoints, stakeholder input, decision-making, constructability, value engineering, design changes, and design approvals.

### Template Language

The project team will establish a design management process that aligns the design with the approved business objectives, intended facility use, scope baseline, budget, schedule, corporate standards, stakeholder requirements, authority requirements, and operational needs. Design deliverables will be reviewed at defined milestones, and material design decisions or changes will be documented, evaluated for cost and schedule impact, and approved through the project governance and change-control process.

### Key Inputs

- Approved business objectives
- Project classification
- Intended facility use
- Scope baseline
- Basis of design or design brief
- Space program
- Corporate standards
- Stakeholder requirements
- Operational requirements
- EHS / safety requirements
- IT / security / AV requirements
- Utility and infrastructure requirements
- Regulatory and permitting requirements
- Budget and schedule constraints
- Delivery method
- Design team scope
- Contractor or construction manager input, if applicable

### Recommended Tables / Checklists

Design deliverables table:

| Design Phase / Deliverable | Purpose | Responsible Party | Reviewers | Target Date | Approval Required? | Notes / Action Required |
| --- | --- | --- | --- | --- | --- | --- |
| Programming / requirements brief | Confirm business, operational, and user requirements | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Concept design | Establish initial planning and design direction | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Schematic design | Confirm layout, systems approach, and scope alignment | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Design development | Advance design detail and cost / schedule alignment | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Construction documents | Issue coordinated documents for bid, permit, or construction | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Permit documents | Support authority review and approval | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Long-lead procurement information | Support early procurement decisions | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Issued-for-bid documents | Support procurement pricing and award | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Issued-for-construction documents | Establish construction document baseline | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Design changes / bulletins | Document approved changes | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |
| As-built / record documents | Support closeout and operations handoff | [Insert] | [Insert] | [Insert] | [Yes / No] | [Insert] |

Design review checkpoint table:

| Review Checkpoint | Review Focus | Participants | Required Inputs | Required Output | Decision / Approval Needed |
| --- | --- | --- | --- | --- | --- |
| Business requirements review | Business objective, user needs, and operating requirements | [Insert] | [Insert] | Confirmed requirements | [Insert] |
| Space program review | Space needs, adjacencies, headcount, and future flexibility | [Insert] | [Insert] | Approved space program | [Insert] |
| Basis of design review | Design criteria, technical assumptions, and standards | [Insert] | [Insert] | Approved basis of design | [Insert] |
| Budget alignment review | Cost alignment with approved budget | [Insert] | [Insert] | Cost action list | [Insert] |
| Schedule alignment review | Design deliverables and procurement / permit timing | [Insert] | [Insert] | Schedule actions | [Insert] |
| Constructability review | Buildability, sequencing, access, interfaces, and risks | [Insert] | [Insert] | Constructability comments | [Insert] |
| Value engineering review | Options, tradeoffs, life-cycle impact, risk, and quality | [Insert] | [Insert] | VE decisions | [Insert] |
| Stakeholder sign-off review | User and functional requirements | [Insert] | [Insert] | Documented sign-off | [Insert] |
| Permit readiness review | Permit documents and authority requirements | [Insert] | [Insert] | Permit readiness confirmation | [Insert] |
| Construction document review | Coordination, completeness, standards, and risks | [Insert] | [Insert] | Review comments / approval | [Insert] |
| Operational readiness / maintainability review | Operations, access, maintenance, training, and turnover | [Insert] | [Insert] | Operations comments | [Insert] |

Design decision log:

| Decision ID | Design Decision Needed | Decision Owner | Required By Date | Cost Impact | Schedule Impact | Risk / Operational Impact | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| DD-001 | [Insert decision] | [Insert owner] | [Insert date] | [Insert] | [Insert] | [Insert] | [Open / Decided / Escalated] |

Design management checklist:

- [ ] Business and operational requirements documented
- [ ] Intended facility use confirmed
- [ ] Design deliverables defined
- [ ] Design review milestones established
- [ ] Stakeholder reviewers identified
- [ ] Corporate standards identified
- [ ] Code and permitting assumptions documented
- [ ] Budget alignment reviewed at design milestones
- [ ] Schedule alignment reviewed at design milestones
- [ ] Constructability input obtained where appropriate
- [ ] Value engineering process defined
- [ ] Design decisions tracked
- [ ] Design changes routed through change control
- [ ] Final design approvals documented
- [ ] Turnover and operations requirements considered during design

### Owner-Side Guidance

The PEP should define the owner-side design management framework, not replace the architect's or engineer's professional design obligations. Owner reviews should focus on whether the design supports the business objective, intended facility use, scope baseline, budget, schedule, stakeholder commitments, operational requirements, safety, quality, maintainability, and turnover expectations.

Stakeholder approval should be structured and time-bound to reduce design churn. Constructability reviews should identify schedule, access, sequencing, procurement, and interface risks. Value engineering should be evaluated against business objectives, lifecycle impact, operational performance, quality, risk, and user experience, not only first cost. Material design changes should be evaluated through change control before approval.

For projects with complex design requirements, use a separate Design Management Plan as a companion planning tool.

### REWS.AI Customization Note

This appendix can be tailored to the project type, intended facility use, design phases, delivery method, corporate standards, design team structure, stakeholder groups, approval workflow, permitting requirements, BIM/CAD standards, constructability process, value engineering process, and design decision log.

## Appendix C: Permitting and Authority Approvals

### Purpose

This appendix defines how the owner-side project team will identify, plan, track, manage, and escalate permitting, entitlement, inspection, approval, and authority requirements that may affect scope, budget, schedule, occupancy, turnover, or operational readiness.

### Template Language

The project team will maintain a permitting and authority approvals strategy that identifies required permits, entitlements, agency reviews, inspections, certifications, landlord/developer approvals, and other authority-related requirements. These requirements will be integrated into the project schedule, risk register, design deliverables, procurement plan, stakeholder communication plan, and turnover readiness process. Material permitting or approval risks will be escalated in accordance with the project governance model.

### Key Inputs

- Project type
- Intended facility use
- Project location
- Site and existing condition information
- Delivery method
- Lease, landlord, or developer obligations
- Authority having jurisdiction requirements
- Entitlement requirements, if applicable
- Building permit requirements
- Trade permit requirements
- Environmental requirements
- Fire/life safety requirements
- Accessibility requirements
- Health, safety, or regulated-use requirements
- Utility provider requirements
- Inspection requirements
- Certificate of occupancy or temporary certificate requirements
- Operational readiness or production approval requirements
- Design deliverables and permit documents
- Baseline schedule

### Recommended Tables / Checklists

Permit and approval matrix:

| Permit / Approval / Inspection | Authority / Approving Party | Responsible Party | Required Submittal | Target Submittal Date | Target Approval / Inspection Date | Schedule Dependency | Risk Level | Status | Notes / Action Required |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Planning or entitlement approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Building permit | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Demolition permit | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Grading / sitework permit | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Fire department review | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Fire alarm / fire sprinkler permit | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Mechanical / electrical / plumbing permits | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Accessibility review | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Environmental approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Hazardous materials approval, if applicable | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Health department approval, if applicable | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Utility provider approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Landlord approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Developer approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Special inspection requirements | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Temporary certificate of occupancy | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Certificate of occupancy | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |
| Operational readiness approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Low / Medium / High] | [Insert] | [Insert] |

AHJ / approving party table:

| Authority / Approving Party | Approval Scope | Primary Contact | Submission Requirements | Review Cycle / Lead Time | Key Risks | Owner-Side Action |
| --- | --- | --- | --- | --- | --- | --- |
| [Insert AHJ / party] | [Insert scope] | [Insert contact] | [Insert requirements] | [Insert lead time] | [Insert risks] | [Insert action] |

Inspection readiness checklist:

- [ ] Required permits identified
- [ ] AHJs and approving parties identified
- [ ] Landlord/developer approvals identified
- [ ] Permit responsibility assigned
- [ ] Permit documents aligned with design schedule
- [ ] Permit durations included in baseline schedule
- [ ] Inspection requirements identified
- [ ] Special inspection requirements identified
- [ ] Utility approval requirements identified
- [ ] Certificate of occupancy requirements identified
- [ ] Business or operational readiness approvals identified
- [ ] Permit and inspection risks included in risk register
- [ ] Permit status included in project reporting
- [ ] Escalation path defined for delayed approvals

### Owner-Side Guidance

The PEP should define how permitting and authority approvals will be managed, not replace jurisdiction-specific legal, code, or permit advice. Project type and intended facility use can materially affect permitting, inspections, regulatory approvals, utility requirements, and occupancy readiness.

Landlord-delivered work, developer-led work, tenant improvement work, build-to-suit projects, and owner-direct packages may create approval interface risks. Permit durations, inspection windows, agency review cycles, and certificate of occupancy or operational readiness requirements should be reflected in the baseline schedule. Delayed permits, failed inspections, or unclear approval responsibilities should be escalated before they affect occupancy, operations, or executive commitments.

For projects with significant permitting, entitlement, inspection, or approval requirements, use a separate Permitting and Entitlements Plan as a companion planning tool.

### REWS.AI Customization Note

This appendix can be tailored to the project location, local authorities, project type, intended facility use, regulatory environment, delivery method, lease obligations, landlord/developer approval process, permit matrix, inspection requirements, utility approvals, local language, and jurisdiction-specific risks.

## Appendix D: Quality Management

### Purpose

This appendix defines the owner-side approach for establishing quality expectations, reviewing design quality, confirming acceptance criteria, managing mockups, coordinating inspections, tracking deficiencies, resolving quality issues, and supporting turnover readiness.

### Template Language

The project team will establish a quality management approach that aligns the delivered project with the approved scope, business objectives, intended facility use, design requirements, corporate standards, regulatory requirements, stakeholder expectations, and turnover readiness criteria. Quality will be managed through defined expectations, design reviews, mockups where appropriate, inspections, issue tracking, punch list management, acceptance criteria, and closeout controls.

### Key Inputs

- Approved scope baseline
- Business objectives and success criteria
- Intended facility use
- Basis of design
- Design documents and specifications
- Corporate standards
- Regulatory and permit requirements
- Stakeholder requirements
- Quality expectations
- Mockup requirements
- Inspection requirements
- Commissioning requirements
- Punch list process
- Acceptance criteria
- Turnover requirements
- Closeout documentation requirements

### Recommended Tables / Checklists

Owner quality expectations table:

| Quality Area | Owner Expectation | Reference Standard / Requirement | Review Method | Responsible Party | Acceptance Criteria |
| --- | --- | --- | --- | --- | --- |
| Design completeness | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Workmanship | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Materials and finishes | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Building systems performance | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Specialty systems | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Lab / manufacturing / technical spaces, if applicable | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| IT / AV / security systems | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Safety and code compliance | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Accessibility | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Maintainability | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Cleanliness and readiness | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |
| Closeout documentation | [Insert expectation] | [Insert standard] | [Insert method] | [Insert] | [Insert criteria] |

Design review and quality checkpoint table:

| Checkpoint | Quality Focus | Participants | Required Evidence | Decision / Approval Needed | Issues to Track |
| --- | --- | --- | --- | --- | --- |
| Programming / requirements review | Requirements completeness | [Insert] | [Insert] | [Insert] | [Insert] |
| Design development review | Coordination, standards, maintainability | [Insert] | [Insert] | [Insert] | [Insert] |
| Construction document review | Completeness, coordination, buildability | [Insert] | [Insert] | [Insert] | [Insert] |
| Mockup review | User expectations, finish quality, performance | [Insert] | [Insert] | [Insert] | [Insert] |
| Pre-installation review | Installation readiness and requirements | [Insert] | [Insert] | [Insert] | [Insert] |
| Above-ceiling / concealed work review | Systems coordination before concealment | [Insert] | [Insert] | [Insert] | [Insert] |
| Substantial completion walk | Punch items and acceptance readiness | [Insert] | [Insert] | [Insert] | [Insert] |
| Punch list review | Deficiency tracking and closure | [Insert] | [Insert] | [Insert] | [Insert] |
| Commissioning / functional testing review | System performance and evidence | [Insert] | [Insert] | [Insert] | [Insert] |
| Turnover readiness review | Owner acceptance and handoff | [Insert] | [Insert] | [Insert] | [Insert] |
| Final acceptance review | Closeout and acceptance criteria | [Insert] | [Insert] | [Insert] | [Insert] |

Mockup / sample / inspection table:

| Item / System | Mockup, Sample, or Inspection Required? | Review Criteria | Reviewer / Approver | Target Date | Status | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| [Insert item / system] | [Yes / No] | [Insert criteria] | [Insert reviewer] | [Insert date] | [Insert status] | [Insert notes] |

Quality issue log:

| Issue ID | Quality Issue / Deficiency | Location / System | Responsible Party | Required Correction | Due Date | Status | Acceptance Confirmation |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Q-001 | [Insert issue] | [Insert location] | [Insert party] | [Insert correction] | [Insert date] | [Open / Closed] | [Insert confirmation] |

Quality checklist:

- [ ] Owner quality expectations documented
- [ ] Relevant corporate standards identified
- [ ] Design quality review checkpoints established
- [ ] Mockups or samples identified where appropriate
- [ ] Inspection requirements identified
- [ ] Quality acceptance criteria documented
- [ ] Specialty spaces or systems reviewed for project-specific quality needs
- [ ] Quality issues tracked and assigned
- [ ] Punch list process defined
- [ ] Deficiency correction process defined
- [ ] Commissioning and quality requirements coordinated
- [ ] Turnover readiness quality checks defined
- [ ] Final acceptance process documented
- [ ] Closeout documentation requirements confirmed

### Owner-Side Guidance

The PEP should define the owner-side quality expectations and quality review framework, not replace contractor quality control obligations or professional design responsibilities. Quality expectations should be defined early because unclear expectations often become late-stage disputes.

Punch list and acceptance criteria should be tied to approved scope, intended facility use, stakeholder requirements, maintainability, commissioning, and turnover readiness. Mockups, samples, and pre-installation reviews can reduce rework and stakeholder disagreement. Turnover quality controls should confirm that deficiencies, training, closeout documentation, commissioning evidence, and final acceptance items are being tracked before occupancy pressure increases.

For projects with significant quality, technical, regulated-use, or turnover requirements, use a separate Quality Management Plan as a companion planning tool.

### REWS.AI Customization Note

This appendix can be tailored to the project type, intended facility use, corporate quality standards, technical systems, regulated-use requirements, inspection requirements, mockup program, commissioning needs, turnover criteria, stakeholder review process, issue tracking tools, and local market expectations.

## Appendix E: Safety Management

### Purpose

This appendix defines the owner-side approach for establishing safety expectations, confirming safety responsibilities, coordinating with EHS and delivery partners, reviewing contractor safety planning, tracking safety performance, reporting incidents, escalating material safety concerns, and aligning the project with applicable safety requirements.

### Template Language

The project team will establish an owner-side safety management approach that confirms safety expectations, roles, reporting requirements, escalation paths, and coordination responsibilities. The contractor, construction manager, landlord, developer, or other delivery partner remains responsible for site-specific safety execution as required by contract, law, regulation, and applicable safety plans. The owner-side project team will coordinate with internal EHS, facilities, operations, security, and delivery partners to support safe project execution and timely escalation of material safety concerns.

### Key Inputs

- Project type
- Intended facility use
- Project location
- Delivery method
- Contract structure
- Contractor / construction manager safety plan
- Owner EHS requirements
- Corporate safety standards
- Site access requirements
- Operational facility constraints
- Occupied-site requirements
- Regulatory requirements
- Incident reporting requirements
- Emergency response requirements
- High-risk work activities
- Permit-to-work requirements, if applicable
- Hazardous materials or regulated-use requirements, if applicable
- Security and visitor access requirements
- Insurance and risk requirements

### Recommended Tables / Checklists

Safety responsibility table:

| Safety Area | Owner-Side Expectation | Responsible Party | Required Evidence / Documentation | Reporting Cadence | Escalation Trigger |
| --- | --- | --- | --- | --- | --- |
| Site-specific safety plan | Contractor / delivery partner safety plan reviewed as required by contract and company process | [Insert] | [Insert] | [Insert] | Missing or inadequate plan |
| Worker orientation / site access | Access requirements and orientation expectations confirmed | [Insert] | [Insert] | [Insert] | Unauthorized or unsafe access |
| Contractor safety meetings | Safety coordination cadence confirmed | [Insert] | [Insert] | [Insert] | Missed meetings or unresolved issues |
| High-risk work planning | High-risk activities identified and coordinated | [Insert] | [Insert] | [Insert] | Unreviewed high-risk activity |
| Incident and near-miss reporting | Notification, documentation, and follow-up expectations defined | [Insert] | [Insert] | [Insert] | Incident, near miss, or late notification |
| Emergency response coordination | Emergency contacts, procedures, and interfaces confirmed | [Insert] | [Insert] | [Insert] | Emergency response gap |
| Occupied-site coordination | Employee, visitor, production, lab, customer, and operational interfaces considered | [Insert] | [Insert] | [Insert] | Occupant or operational exposure |
| Hot work / permit-to-work, if applicable | Permit process and controls confirmed | [Insert] | [Insert] | [Insert] | Permit gap or unsafe activity |
| Hazardous materials coordination, if applicable | Responsibilities and controls confirmed | [Insert] | [Insert] | [Insert] | Exposure or compliance risk |
| Utility shutdowns or energized work | Planning, notifications, and approvals confirmed | [Insert] | [Insert] | [Insert] | Unplanned outage or safety exposure |
| Fire/life safety systems | Impairments, inspections, and temporary measures coordinated | [Insert] | [Insert] | [Insert] | Life safety impairment |
| Security and access control | Site security and visitor access requirements coordinated | [Insert] | [Insert] | [Insert] | Security or public access concern |
| Safety audits / observations | Observation cadence and follow-up process defined | [Insert] | [Insert] | [Insert] | Serious or repeated finding |
| Regulatory inspections or notices | Notification and escalation process defined | [Insert] | [Insert] | [Insert] | Inspection, citation, or notice |

High-risk work / safety interface table:

| Activity / Interface | Potential Safety Concern | Responsible Party | Required Control / Coordination | Owner-Side Review Required? | Status / Notes |
| --- | --- | --- | --- | --- | --- |
| Work in occupied facilities | Employee, visitor, customer, or operations exposure | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Demolition | Dust, noise, structural, hazardous material, or access risk | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Crane / lift operations | Public, employee, access, or logistics risk | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Hot work | Fire risk, fire watch, permit-to-work needs | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Electrical work | Energized work, shutdowns, lockout/tagout interfaces | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Utility shutdowns | Operational impact, notification, emergency procedures | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Confined space work | Entry controls and rescue planning | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Roof work / fall exposure | Fall protection and access control | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Hazardous materials | Exposure, containment, disposal, compliance | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Work near production or lab operations | Operational disruption, contamination, exposure | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Fire alarm / sprinkler impairments | Life safety coverage and notifications | [Insert] | [Insert] | [Yes / No] | [Insert] |
| Public or employee access interfaces | Barriers, signage, logistics, security | [Insert] | [Insert] | [Yes / No] | [Insert] |

Incident reporting and escalation table:

| Event Type | Initial Notification Requirement | Required Recipients | Documentation Required | Escalation Level | Follow-Up Action |
| --- | --- | --- | --- | --- | --- |
| First aid event | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Recordable incident | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Lost-time incident | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Near miss | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Property damage | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Utility strike | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Fire/life safety event | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Regulatory inspection or citation | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Public impact or security incident | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |
| Serious injury or fatality | [Insert requirement] | [Insert recipients] | [Insert documentation] | [Insert level] | [Insert action] |

Safety checklist:

- [ ] Owner EHS requirements identified
- [ ] Contractor safety plan requirement confirmed
- [ ] Site-specific safety responsibilities documented
- [ ] Occupied-site constraints identified
- [ ] High-risk work activities identified
- [ ] Site access and orientation requirements defined
- [ ] Incident reporting requirements defined
- [ ] Escalation triggers defined
- [ ] Emergency response coordination confirmed
- [ ] Regulatory requirements reviewed
- [ ] Safety reporting cadence established
- [ ] Safety observations or audits planned where appropriate
- [ ] Safety interfaces with operations, facilities, security, and stakeholders identified
- [ ] Safety requirements reviewed during procurement and contract setup
- [ ] Safety expectations communicated before work starts

### Owner-Side Guidance

The PEP should define owner-side safety expectations and coordination requirements, not replace the contractor's site-specific safety plan or legal safety obligations. Safety responsibility should be aligned with the delivery method, contract structure, project location, and applicable law.

Owner-side project managers should coordinate closely with EHS, facilities, operations, security, landlords, developers, and delivery partners. Projects in occupied facilities require added attention to employee, visitor, production, lab, customer, and operational interfaces. High-risk activities should be identified early and reviewed for coordination, access, communication, emergency response, and escalation needs.

For projects with significant safety, EHS, occupied-site, or high-risk work considerations, use a separate Safety Management Plan as a companion planning tool.

### REWS.AI Customization Note

A customized version may adapt this appendix to the project location, local safety regulations, company EHS requirements, contract structure, occupied-site constraints, high-risk activities, incident reporting requirements, and emergency contacts.

## Appendix F: Commissioning, Turnover, and Closeout

### Purpose

This appendix defines the owner-side approach for planning, managing, verifying, and completing commissioning, turnover, occupancy readiness, operational handoff, closeout documentation, warranty setup, asset data transfer, training, final acceptance, and lessons learned.

### Template Language

The project team will establish a commissioning, turnover, and closeout process that confirms the project is ready for occupancy, operations, maintenance, and business use. Turnover readiness will be planned before the end of construction and coordinated with facilities, operations, EHS, IT, security, end users, vendors, consultants, contractors, landlords, developers, and other responsible parties. Closeout will include required documents, training, warranties, asset data, as-builts, punch list completion, acceptance criteria, and lessons learned.

### Key Inputs

- Project type
- Intended facility use
- Business readiness requirements
- Operational readiness date
- Occupancy requirements
- Commissioning requirements
- Systems requiring testing or verification
- Regulatory or authority approval requirements
- Certificate of occupancy or equivalent approval
- Quality acceptance criteria
- Punch list process
- Training requirements
- O&M documentation requirements
- Warranty requirements
- As-built / record document requirements
- Asset data requirements
- Facilities / operations handoff requirements
- IT / AV / security turnover requirements
- Specialty equipment turnover requirements
- Landlord / developer turnover obligations, if applicable
- Closeout documentation requirements

### Recommended Tables / Checklists

Commissioning and turnover matrix:

| System / Area / Deliverable | Turnover Requirement | Responsible Party | Required Evidence | Target Completion Date | Owner / Approver | Status | Notes / Action Required |
| --- | --- | --- | --- | --- | --- | --- | --- |
| HVAC systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Electrical systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Plumbing systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Fire/life safety systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Building automation / controls | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| IT / AV / security systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Specialty equipment | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Lab / manufacturing / technical systems, if applicable | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Furniture, fixtures, and equipment | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Operations and maintenance manuals | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Warranties | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| As-builts / record documents | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Asset data | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Training | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Punch list | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Certificate of occupancy or equivalent approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Final acceptance | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Owner readiness checklist:

- [ ] Occupancy or operational readiness date confirmed
- [ ] Commissioning scope defined
- [ ] Required systems identified
- [ ] Turnover requirements documented
- [ ] Facilities / operations team engaged
- [ ] IT / AV / security handoff requirements identified
- [ ] Training requirements identified
- [ ] O&M document requirements confirmed
- [ ] Warranty requirements confirmed
- [ ] Asset data requirements confirmed
- [ ] Punch list process established
- [ ] Acceptance criteria documented
- [ ] Certificate of occupancy or required approvals tracked
- [ ] Move / occupancy readiness coordinated
- [ ] Closeout documentation tracker established
- [ ] Lessons learned session planned

Training and handoff table:

| Training / Handoff Topic | Audience | Provider | Required Date | Required Materials | Completion Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| Building systems operations | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Controls / BMS | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Fire/life safety systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Security systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| IT / AV systems | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Specialty equipment | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Cleaning / maintenance requirements | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Warranty process | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Emergency procedures | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Occupant or user orientation | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Closeout document tracker:

| Closeout Item | Required? | Responsible Party | Due Date | Received? | Accepted? | Notes / Action Required |
| --- | --- | --- | --- | --- | --- | --- |
| As-built / record drawings | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| O&M manuals | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Warranties | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Training records | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Commissioning reports | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Test and inspection records | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Permit closeout documentation | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Certificate of occupancy or equivalent approval | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Asset data | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Spare parts / attic stock | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Final lien waivers, if applicable | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Final account / cost reconciliation | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |
| Lessons learned summary | [Yes / No] | [Insert] | [Insert] | [Yes / No] | [Yes / No] | [Insert] |

### Owner-Side Guidance

The PEP should define the owner-side turnover and closeout framework, not replace detailed commissioning specifications or contractor closeout obligations. Turnover planning should begin early, not after substantial completion.

Different project types require different closeout intensity. Office projects, labs, manufacturing, data centers, cleanrooms, and regulated-use spaces may require different levels of commissioning, documentation, training, warranty setup, as-built records, asset data, and operational readiness evidence. Punch list completion should be tied to acceptance criteria and operational readiness, not merely visual inspection.

For projects with significant commissioning, turnover, training, asset data, warranty, or operational readiness requirements, use a separate Commissioning and Turnover Plan as a companion planning tool.

### REWS.AI Customization Note

This appendix can be tailored to project type, intended facility use, commissioning scope, asset data requirements, training needs, warranty requirements, authority approvals, landlord/developer obligations, and operational readiness criteria.

## Appendix G: KPI and Performance Reporting

### Purpose

This appendix defines the owner-side approach for tracking project health, performance trends, decision needs, risks, and readiness using practical key performance indicators and reporting conventions.

### Template Language

The project team will maintain a practical performance reporting framework to track project health, support timely decisions, identify risks, and provide visibility to sponsors and leadership. KPIs will be scaled based on project complexity, governance requirements, stakeholder impact, and business risk. Performance reporting should be forward-looking and should identify actions required to protect the approved scope, budget, schedule, quality, safety, and business readiness commitments.

### Key Inputs

- Approved scope baseline
- Approved budget baseline
- Approved baseline schedule
- Project complexity level
- Governance model
- Reporting cadence
- Risk register
- Change log
- Decision log
- Procurement tracker
- Schedule milestone tracker
- Cost report
- Safety reporting
- Quality / punch tracking
- Commissioning and closeout tracker
- Executive reporting requirements

### Recommended Tables / Checklists

KPI table:

| KPI / Metric | Purpose | Data Source | Reporting Frequency | Target / Threshold | Current Status | Owner | Escalation Trigger |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Overall project RAG status | Summarize overall health | Executive snapshot | [Insert] | [Insert] | [Green / Yellow / Red] | [Insert] | [Insert] |
| Budget variance | Track budget pressure | Cost report | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Forecast-at-completion variance | Track forecast outcome | Cost report | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Contingency remaining | Track contingency position | Contingency log | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Schedule variance | Track milestone movement | Schedule tracker | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Milestone performance | Track milestone delivery | Milestone tracker | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Critical path risk | Track schedule protection | Schedule report | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Open high-priority risks | Track risk exposure | Risk register | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Open change requests | Track change volume and impacts | Change log | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Pending decision aging | Track delayed owner decisions | Decision log | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Procurement package status | Track procurement readiness | Procurement tracker | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Long-lead item status | Track long-lead risks | Procurement / schedule tracker | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Safety incidents / observations | Track safety performance | Safety report | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Quality issues / open punch items | Track quality closure | Quality issue log | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Commissioning readiness | Track turnover readiness | Commissioning tracker | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Turnover / closeout readiness | Track handoff and closeout | Closeout tracker | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Executive actions required | Track leadership actions | Executive snapshot | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

RAG status table:

| Status Area | Green Definition | Yellow Definition | Red Definition | Escalation Required? |
| --- | --- | --- | --- | --- |
| Overall project | Tracking to approved expectations | Issues require active management | Material issue requires escalation | [Yes / No] |
| Budget | Forecast within approved budget | Forecast pressure manageable within governance | Budget increase or material cost issue likely | [Yes / No] |
| Schedule | Forecast meets required dates | Delays manageable with recovery actions | Material impact to business date or commitment | [Yes / No] |
| Scope / change | Scope stable and changes controlled | Pending changes require active review | Major scope change or uncontrolled change risk | [Yes / No] |
| Risk | Risks within tolerance | Elevated risks under mitigation | Material risk requires leadership action | [Yes / No] |
| Safety | No material concerns | Issues require active management | Serious incident or material safety concern | [Yes / No] |
| Quality | Quality tracking to expectations | Issues require correction | Material quality or acceptance issue | [Yes / No] |
| Procurement | Packages tracking to plan | Procurement delays manageable | Award or long-lead delay affects project | [Yes / No] |
| Stakeholder / decisions | Decisions tracking to required dates | Decision aging requires follow-up | Decision delay threatens cost, schedule, or readiness | [Yes / No] |
| Commissioning / turnover | Readiness tracking to plan | Readiness gaps under active management | Material turnover or occupancy risk | [Yes / No] |

Reporting cadence table:

| Report / Forum | Audience | Purpose | Frequency | Owner | Required Inputs | Output / Decision Needed |
| --- | --- | --- | --- | --- | --- | --- |
| Weekly project team status | Project team | Coordinate actions, risks, issues, and near-term work | Weekly | Owner PM | Action log, schedule, issues | Updated actions |
| Monthly sponsor update | Sponsor / RE leader | Review project health and decisions | Monthly | Owner PM | Executive snapshot, cost, schedule, risks | Decisions / direction |
| Cost and schedule review | Owner PM, finance, project controls | Review forecast, commitments, milestones, and recovery actions | Monthly | Owner PM / finance | Cost report, schedule tracker | Cost / schedule actions |
| Risk and change review | Project leadership | Review risks, changes, decision needs, and escalations | Monthly or as needed | Owner PM | Risk register, change log, decision log | Approvals / escalations |
| Procurement status review | Owner PM, procurement, finance | Review packages, awards, long-lead items, and interfaces | Monthly or procurement cadence | Owner PM / procurement | Procurement tracker | Procurement actions |
| Executive reporting snapshot | Sponsor / leadership | Provide concise view of project health and leadership actions | Monthly or governance cadence | Owner PM | KPI table, RAG status, cost, schedule, risks | Executive action |
| Steering committee update, if applicable | Steering committee | Review major decisions, escalations, funding, and business readiness | Governance cadence | Sponsor / Owner PM | Executive report | Approvals / direction |
| Turnover readiness review | Facilities, operations, IT, security, stakeholders | Confirm readiness and closeout actions | As needed near turnover | Owner PM | Commissioning and closeout trackers | Readiness actions |

Project controls checklist:

- [ ] KPI set selected based on project complexity
- [ ] RAG definitions agreed
- [ ] Budget and forecast metrics defined
- [ ] Schedule and milestone metrics defined
- [ ] Risk and change metrics defined
- [ ] Decision aging tracked
- [ ] Procurement and long-lead metrics tracked
- [ ] Safety and quality reporting included
- [ ] Commissioning and closeout readiness tracked
- [ ] Data sources identified
- [ ] Reporting cadence established
- [ ] KPI owners assigned
- [ ] Escalation thresholds defined
- [ ] Executive reporting aligned with governance model

### Owner-Side Guidance

The PEP should define the performance reporting framework, not replace the detailed project dashboard. KPIs should support decision-making and escalation, not simply report activity.

Decision aging is a useful owner-side metric because delayed decisions often become cost, schedule, stakeholder, and business-readiness risks. Budget and schedule reporting should be forward-looking and based on forecast outcomes, not only historical actuals. KPI reporting should connect to executive reporting, risk management, change control, and closeout readiness.

For projects requiring more formal performance reporting, use a separate Project KPI Dashboard Template as a companion reporting tool.

### REWS.AI Customization Note

This appendix can be tailored to the company's project controls standards, reporting cadence, RAG definitions, budget categories, milestone structure, approval thresholds, dashboard format, governance model, data sources, and executive reporting requirements.

## Appendix H: Sustainability, ESG, and Corporate Standards

### Purpose

This appendix defines the owner-side approach for identifying, documenting, managing, and reporting sustainability goals, ESG requirements, corporate standards, certification objectives, energy and water expectations, waste requirements, materials considerations, and related design, procurement, construction, commissioning, and turnover implications.

### Template Language

The project team will identify applicable sustainability, ESG, and corporate standards requirements early in the project lifecycle and incorporate them into the project scope, design criteria, procurement strategy, budget, schedule, quality expectations, commissioning requirements, turnover documentation, and reporting process. Sustainability and corporate standards requirements will be scaled based on project type, intended facility use, company commitments, regulatory requirements, certification goals, business objectives, and operational needs.

### Key Inputs

- Company sustainability standards
- Corporate real estate standards
- Workplace standards
- Facilities / operations standards
- Energy performance requirements
- Water performance requirements
- Waste diversion requirements
- Materials and finish standards
- Carbon or embodied carbon goals, if applicable
- Certification goals, if applicable
- ESG reporting requirements
- Local regulatory requirements
- Utility requirements
- Commissioning requirements
- Design standards
- Procurement requirements
- Operational performance expectations
- Turnover documentation requirements

### Recommended Tables / Checklists

Sustainability and corporate standards table:

| Requirement Area | Applicable Requirement / Goal | Source / Standard | Responsible Party | Design / Procurement / Construction Impact | Evidence Required | Status |
| --- | --- | --- | --- | --- | --- | --- |
| Energy performance | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Water efficiency | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Waste diversion | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Materials and finishes | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Indoor environmental quality | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Carbon / embodied carbon, if applicable | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Certification target, if applicable | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Corporate workplace standards | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Corporate facilities standards | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Operations and maintenance standards | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Utility metering / monitoring | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Commissioning requirements | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| ESG reporting requirements | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Certification / reporting table:

| Certification / Reporting Requirement | Required? | Target Level / Outcome | Responsible Party | Key Deliverables | Target Date | Risk / Notes |
| --- | --- | --- | --- | --- | --- | --- |
| LEED, if applicable | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| WELL, if applicable | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Fitwel, if applicable | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Energy performance reporting | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Water reporting | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Waste reporting | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Carbon reporting | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Corporate ESG reporting | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Local jurisdictional reporting | [Yes / No / TBD] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Corporate standards checklist:

- [ ] Corporate real estate standards identified
- [ ] Workplace standards identified
- [ ] Facilities / operations standards identified
- [ ] Sustainability requirements identified
- [ ] ESG reporting requirements identified
- [ ] Certification goals confirmed, if applicable
- [ ] Energy and water requirements documented
- [ ] Waste requirements documented
- [ ] Materials requirements documented
- [ ] Design implications reviewed
- [ ] Procurement implications reviewed
- [ ] Budget and schedule impacts reviewed
- [ ] Commissioning implications reviewed
- [ ] Turnover documentation requirements confirmed
- [ ] Evidence and reporting requirements assigned
- [ ] Sustainability risks added to risk register where appropriate

### Owner-Side Guidance

The PEP should identify applicable sustainability, ESG, and corporate standards requirements, not replace a detailed sustainability strategy or certification plan. Sustainability goals should be confirmed early because they can affect design, procurement, cost, schedule, commissioning, turnover, and operations.

Corporate standards should be reviewed before design and procurement decisions are locked. Certification goals should be translated into specific project requirements, deliverables, responsibilities, and evidence requirements. ESG reporting needs should be coordinated with finance, sustainability, facilities, operations, procurement, and corporate reporting teams where applicable.

For projects with defined sustainability, ESG, certification, or corporate standards requirements, use a separate Sustainability and ESG Plan as a companion planning tool.

### REWS.AI Customization Note

This appendix can be tailored to the company's corporate standards, sustainability commitments, ESG reporting requirements, project type, intended facility use, location, local regulations, certification goals, energy and water requirements, waste diversion targets, materials standards, procurement requirements, commissioning requirements, and turnover documentation needs.

## Appendix I: Document Control and Information Management

### Purpose

This appendix defines the owner-side approach for organizing, controlling, storing, approving, retrieving, and preserving project information, including project records, meeting minutes, design documents, contracts, approvals, decisions, RFIs, submittals, changes, reports, closeout documents, and turnover records.

### Template Language

The project team will maintain a defined document control and information management process to support effective project execution, decision-making, accountability, reporting, and closeout. Project information will be organized in an agreed system of record, with clear expectations for document ownership, version control, naming conventions, access permissions, approval records, decision records, reporting artifacts, and closeout documentation.

### Key Inputs

- Project repository or document management platform
- Company document control standards
- Contract document requirements
- Design document requirements
- Approval records
- Meeting records
- RFI and submittal process
- Change management records
- Decision log
- Risk register
- Cost and schedule reports
- Executive reporting artifacts
- Permitting and authority records
- Quality, safety, and commissioning records
- Closeout documentation requirements
- Retention requirements
- Access and permissions requirements

### Recommended Tables / Checklists

Project repository structure:

| Folder / Record Category | Purpose | Owner | Required Content | Access / Permissions | Retention / Closeout Requirement |
| --- | --- | --- | --- | --- | --- |
| Governance and approvals | Store project governance records and approvals | [Insert] | [Insert] | [Insert] | [Insert] |
| Business case and funding approvals | Preserve approval basis and funding record | [Insert] | [Insert] | [Insert] | [Insert] |
| Scope and project requirements | Maintain approved scope and requirements | [Insert] | [Insert] | [Insert] | [Insert] |
| Contracts and procurement | Store procurement records and contracts | [Insert] | [Insert] | [Insert] | [Insert] |
| Design documents | Maintain current and historical design deliverables | [Insert] | [Insert] | [Insert] | [Insert] |
| Permits and authority approvals | Store permit and inspection records | [Insert] | [Insert] | [Insert] | [Insert] |
| Meeting minutes and action logs | Document meetings, actions, and commitments | [Insert] | [Insert] | [Insert] | [Insert] |
| RFI and submittal records | Preserve questions, responses, and reviews | [Insert] | [Insert] | [Insert] | [Insert] |
| Cost reports and invoices | Store cost reports, invoices, and payment records | [Insert] | [Insert] | [Insert] | [Insert] |
| Schedule reports | Maintain baseline, updates, and milestone reports | [Insert] | [Insert] | [Insert] | [Insert] |
| Risk, issue, change, and decision logs | Preserve project controls records | [Insert] | [Insert] | [Insert] | [Insert] |
| Safety records | Store safety reports, incidents, and observations | [Insert] | [Insert] | [Insert] | [Insert] |
| Quality records | Maintain inspections, deficiencies, and acceptance evidence | [Insert] | [Insert] | [Insert] | [Insert] |
| Commissioning records | Store testing, commissioning, and training records | [Insert] | [Insert] | [Insert] | [Insert] |
| Turnover and closeout documents | Preserve closeout deliverables and acceptance records | [Insert] | [Insert] | [Insert] | [Insert] |
| Executive reports | Archive sponsor updates and executive reporting snapshots | [Insert] | [Insert] | [Insert] | [Insert] |

Document control table:

| Document Type | System of Record | Document Owner | Naming / Version Convention | Review / Approval Requirement | Distribution / Access | Closeout Requirement |
| --- | --- | --- | --- | --- | --- | --- |
| [Insert document type] | [Insert platform] | [Insert owner] | [Insert convention] | [Insert requirement] | [Insert access] | [Insert requirement] |

Decision and approval record table:

| Record Type | Decision / Approval Owner | Required Evidence | Storage Location | Required By | Status | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| Capital approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Scope approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Budget approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Schedule baseline approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Procurement award approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Change approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Contingency use approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Design approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Permit approval | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Turnover acceptance | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |
| Final closeout acceptance | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Document control checklist:

- [ ] System of record identified
- [ ] Repository structure established
- [ ] Document owners assigned
- [ ] Access permissions confirmed
- [ ] Naming conventions defined
- [ ] Version control expectations defined
- [ ] Meeting minutes process established
- [ ] Action log process established
- [ ] Decision log process established
- [ ] Approval records stored in agreed location
- [ ] RFI and submittal governance aligned with delivery partners
- [ ] Change records tied to cost and schedule records
- [ ] Executive reports archived
- [ ] Closeout document requirements identified
- [ ] Turnover records identified
- [ ] Retention requirements reviewed
- [ ] Final project archive process defined

### Owner-Side Guidance

The PEP should define the owner-side information management framework, not replace a detailed document control procedure or legal records policy. Project decisions should be documented in a retrievable system of record.

Version control is important because outdated scopes, budgets, schedules, drawings, and approval records can create confusion and risk. Closeout records should be defined early so required O&M manuals, warranties, as-builts, asset data, commissioning reports, and acceptance records are not pursued too late.

For projects requiring more formal information management, use a separate Document Control Plan as a companion project controls tool.

### REWS.AI Customization Note

This appendix can be tailored to the company's document control standards, repository platform, naming conventions, approval workflows, access permissions, contract structure, delivery method, RFI/submittal process, reporting artifacts, closeout records, retention requirements, and project management tools.

## Appendix J: Lessons Learned

### Purpose

This appendix defines the owner-side approach for capturing, reviewing, documenting, and applying lessons learned from the project so future projects can benefit from improved planning, governance, procurement, design, execution, stakeholder management, turnover, and vendor performance.

### Template Language

The project team will capture lessons learned throughout the project lifecycle and complete a formal lessons learned review during closeout. Lessons learned should identify what worked well, what did not work well, root causes, impacts, recommendations, accountable owners, and reusable improvements for future projects. Lessons should be organized so they can inform future project planning, vendor selection, project controls, design standards, procurement strategy, governance, and company template improvements.

### Key Inputs

- Project objectives and success criteria
- Final budget and cost performance
- Final schedule and milestone performance
- Change log
- Risk register
- Decision log
- Issue log
- Procurement outcomes
- Vendor performance observations
- Design review outcomes
- Quality and punch list outcomes
- Safety observations
- Commissioning and turnover outcomes
- Stakeholder feedback
- Closeout documentation
- Executive sponsor feedback
- Facilities / operations feedback
- End-user feedback

### Recommended Tables / Checklists

Lessons learned table:

| Lesson ID | Category | What Happened | Impact | Root Cause / Contributing Factor | Recommendation | Future Project Application | Owner | Priority |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| LL-001 | Scope definition | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |
| LL-002 | Governance and approvals | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |
| LL-003 | Budget and cost control | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |
| LL-004 | Schedule management | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |
| LL-005 | Procurement and contracting | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |
| LL-006 | Design management | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |
| LL-007 | Commissioning and turnover | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |
| LL-008 | Facilities / operations handoff | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] | [High / Medium / Low] |

Vendor / partner performance table:

| Vendor / Partner | Role | What Worked Well | Issues / Concerns | Impact | Recommended Future Action | Owner / Reviewer |
| --- | --- | --- | --- | --- | --- | --- |
| [Insert vendor / partner] | [Insert role] | [Insert] | [Insert] | [Insert] | [Insert] | [Insert] |

Future improvement action table:

| Improvement Action | Source Lesson | Applies To | Priority | Owner | Target Date | Status |
| --- | --- | --- | --- | --- | --- | --- |
| [Insert action] | [Insert lesson ID] | Future project intake | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Project Execution Plan | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Scope template | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Procurement strategy | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Design review process | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Change management process | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Vendor selection | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Commissioning and turnover | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Corporate standard | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |
| [Insert action] | [Insert lesson ID] | Company template update | [High / Medium / Low] | [Insert] | [Insert] | [Insert] |

Lessons learned checklist:

- [ ] Lessons captured during project phases
- [ ] Closeout lessons learned meeting scheduled
- [ ] Project sponsor feedback collected
- [ ] Owner PM feedback collected
- [ ] Stakeholder feedback collected
- [ ] Design and delivery partner feedback collected
- [ ] Facilities / operations feedback collected
- [ ] End-user feedback collected where appropriate
- [ ] Cost and schedule drivers reviewed
- [ ] Change and risk trends reviewed
- [ ] Vendor performance reviewed
- [ ] Commissioning and turnover lessons reviewed
- [ ] Actionable recommendations documented
- [ ] Future project improvements assigned to owners
- [ ] Lessons archived in the project record
- [ ] Relevant lessons incorporated into templates, standards, or future planning

### Owner-Side Guidance

Lessons learned should not be treated as a formality at the end of the project. The most useful lessons are specific, evidence-based, and tied to future actions.

The owner-side project manager should confirm lessons are stored where future teams can actually find and use them. Vendor and partner performance feedback should be factual, fair, and useful for future procurement decisions. Closeout is an opportunity to improve future project intake, scoping, budgeting, scheduling, procurement, governance, design review, change control, commissioning, turnover, and knowledge management.

For projects requiring a facilitated closeout review, use a separate Lessons Learned Workshop Template as a companion closeout tool.

### REWS.AI Customization Note

This appendix can be tailored to the company's lessons learned process, project type, delivery method, vendor evaluation criteria, project controls standards, stakeholder feedback process, knowledge management system, closeout process, and continuous improvement workflow.

## Appendix K: Templates and Logs

### Purpose

This appendix identifies the practical templates, trackers, logs, and companion tools that support use of the Project Execution Plan.

### Template Language

The project team will maintain the templates and logs required to support project governance, reporting, decision-making, risk management, change control, stakeholder alignment, project controls, turnover, and closeout. The specific tools used should be scaled to the project's complexity level, delivery method, stakeholder impact, reporting requirements, and company standards.

### Key Inputs

- Project complexity level
- Governance model
- Reporting requirements
- Company standards
- Project controls requirements
- Budget and schedule reporting needs
- Risk, issue, change, and decision tracking needs
- Procurement and permitting tracking needs
- Quality and safety tracking needs
- Commissioning and closeout tracking needs
- System of record
- Tool / software requirements

### Recommended Tables / Checklists

Templates and logs index:

| Template / Log | Purpose | Required for Level 1? | Required for Level 2? | Required for Level 3? | Owner | Update Cadence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Project Charter or Project Summary | Summarize purpose, scope, sponsor, budget, schedule, and success criteria | Yes | Yes | Yes | [Insert] | At initiation and major changes | [Insert] |
| Project Classification Table | Classify project type, intended use, and complexity drivers | Yes | Yes | Yes | [Insert] | At initiation and scope changes | [Insert] |
| Project Complexity and Controls Assessment | Determine governance, reporting, controls, and appendices | Yes | Yes | Yes | [Insert] | At initiation and phase transitions | [Insert] |
| Governance and Approval Matrix | Define decision rights and approval thresholds | Simple | Yes | Yes | [Insert] | At initiation and governance changes | [Insert] |
| RACI Matrix | Clarify accountability and responsibility | Optional | Yes | Yes | [Insert] | At initiation and phase transitions | [Insert] |
| Stakeholder Register | Track stakeholders, needs, and decision roles | Simple | Yes | Yes | [Insert] | Monthly or as stakeholders change | [Insert] |
| Communication Matrix | Define forums, reports, audiences, and cadence | Simple | Yes | Yes | [Insert] | At initiation and as cadence changes | [Insert] |
| Executive Reporting Snapshot | Provide concise leadership visibility | Optional | Yes | Yes | [Insert] | Monthly or governance cadence | [Insert] |
| Budget Tracker | Track budget, commitments, actuals, forecast, and variance | Yes | Yes | Yes | [Insert] | Monthly or agreed cadence | [Insert] |
| Cost Report | Report cost performance and forecast | Optional | Yes | Yes | [Insert] | Monthly or agreed cadence | [Insert] |
| Contingency Log | Track contingency use and remaining balance | Optional | Yes | Yes | [Insert] | Monthly or with changes | [Insert] |
| Milestone Tracker | Track baseline dates, forecast dates, and variance | Yes | Yes | Yes | [Insert] | Weekly or monthly | [Insert] |
| Risk Register | Track risks, owners, mitigation actions, and escalation | Simple | Yes | Yes | [Insert] | Biweekly or monthly | [Insert] |
| Issue Log | Track active issues and resolution status | Optional | Yes | Yes | [Insert] | Weekly or agreed cadence | [Insert] |
| Change Log | Track proposed, approved, rejected, and deferred changes | Simple | Yes | Yes | [Insert] | With each change cycle | [Insert] |
| Decision Log | Track decisions, owners, due dates, and delay impacts | Simple | Yes | Yes | [Insert] | Weekly or agreed cadence | [Insert] |
| Procurement Matrix | Track packages, awards, approvals, and risks | Optional | Yes | Yes | [Insert] | Monthly or procurement cadence | [Insert] |
| Permit Matrix | Track permits, inspections, approvals, and target dates | Optional | Yes | Yes | [Insert] | Monthly or permitting cadence | [Insert] |
| Quality Issue Log | Track deficiencies, corrections, and acceptance | Optional | Yes | Yes | [Insert] | Weekly during execution | [Insert] |
| Safety Observation Log | Track observations, incidents, and follow-up actions | Optional | Yes | Yes | [Insert] | Weekly or incident-driven | [Insert] |
| KPI Dashboard | Track project health indicators and escalation thresholds | Optional | Optional | Yes | [Insert] | Monthly or reporting cadence | [Insert] |
| Commissioning and Turnover Matrix | Track systems, deliverables, evidence, and readiness | Optional | Yes | Yes | [Insert] | Monthly, then weekly near turnover | [Insert] |
| Closeout Tracker | Track closeout deliverables and acceptance | Yes | Yes | Yes | [Insert] | Monthly, then weekly near closeout | [Insert] |
| Lessons Learned Log | Capture lessons, recommendations, and future applications | Optional | Yes | Yes | [Insert] | Phase transitions and closeout | [Insert] |

Minimum toolkit by complexity level:

| Complexity Level | Minimum Recommended Tools | Optional Tools | Notes |
| --- | --- | --- | --- |
| Level 1: Small / Low Complexity | Project summary, project classification, basic controls assessment, simple budget tracker, milestone tracker, change log, decision log, closeout tracker | Simple stakeholder register, risk log, communication matrix, lessons learned log | Keep tools lightweight and focused on decisions, approvals, cost, schedule, and closeout. |
| Level 2: Medium / Moderate Complexity | Project summary, classification, controls assessment, governance matrix, RACI, stakeholder register, communication matrix, budget tracker, cost report, milestone tracker, risk register, issue log, change log, decision log, procurement matrix, permit matrix, closeout tracker | Executive snapshot, contingency log, design decision log, quality issue log, safety observation log, commissioning matrix, lessons learned log | Use formal trackers where multiple stakeholders, approvals, packages, or project risks need coordination. |
| Level 3: Large / High Complexity | Full project controls workbook including governance matrix, RACI, stakeholder register, communication matrix, executive snapshot, budget tracker, cost report, contingency log, milestone tracker, risk register, issue log, change log, decision log, procurement matrix, permit matrix, quality issue log, safety log, KPI dashboard, commissioning and turnover matrix, closeout tracker, lessons learned log | Additional program, portfolio, regulatory, EHS, commissioning, vendor, or dashboard tools as required | Use more formal project controls because decisions, interfaces, business risk, reporting, and closeout complexity are higher. |

Project controls toolkit checklist:

- [ ] Required templates and logs selected based on complexity level
- [ ] Owners assigned for each tracker
- [ ] Update cadence established
- [ ] System of record identified
- [ ] Reporting dependencies confirmed
- [ ] Budget and schedule trackers aligned with executive reporting
- [ ] Risk, issue, change, and decision logs coordinated
- [ ] Procurement and permit trackers aligned with the schedule
- [ ] Quality, safety, commissioning, and closeout trackers aligned with turnover requirements
- [ ] Lessons learned log established before closeout
- [ ] Templates reviewed at major phase transitions

### Owner-Side Guidance

The PEP should identify the project controls toolkit, not replace every detailed tracker. Smaller projects should use lightweight logs to avoid unnecessary administration, while larger or higher-risk projects should use more formal project controls tools.

Risk, issue, change, and decision logs should be coordinated because they often affect each other. Budget, schedule, procurement, permitting, and closeout trackers should feed executive reporting. Tools should support decisions and accountability, not create administrative burden.

For projects requiring an integrated set of trackers, use a separate Project Controls Workbook as a companion project controls tool.

### REWS.AI Customization Note

A customized version may recommend an appropriate project controls toolkit based on project complexity, project type, intended facility use, delivery method, governance model, company standards, reporting cadence, approval thresholds, tools/software, and closeout requirements.