Project Charter Template Prince2

Standard Operating Procedure: PRINCE2 Project Charter (Project Brief) Initialization

---

1. Document Control Block

• Document ID: SOP-TR-PM-042
• Effective Date: October 24, 2023
• Version: 3.2.0
• Review Cadence: Annual / Post-Project Audit
• Owner: Julian Vance, Chief Architect, Template Registry
• Classification: Institutional Standard

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional engineering standard for authoring, reviewing, and baselining a PRINCE2-compliant Project Charter (formally designated as the Project Brief within the PRINCE2 methodology).

The purpose of this procedure is to establish a rigorous, repeatable protocol ensuring that all initiatives entering the Template Registry ecosystem possess a justified business case, clearly defined boundaries, designated governance structures, and measurable tolerances before committing capital or engineering resources.

---

3. Scope & Prerequisites

Scope

This procedure applies to all internal and client-facing projects managed under the Template Registry governance framework. It governs the transition from Pre-Project (PRINCE2 Starting up a Project process) to initiating the project.

Prerequisites & Required Tools

• Access to the Template Registry Project Management Information System (PMIS / Jira / Confluence).
• PRINCE2 7th Edition Foundation or Practitioner certification (for the designated Project Manager).
• Approved Project Mandate (or business initiator brief).
• Access to the Enterprise Risk Management (ERM) repository.

---

4. Roles & Responsibilities (RACI Matrix)

Legend:

• R = Responsible (The role that performs the activity)
• A = Accountable (The sole role with final approval authority)
• Consulted (Role providing critical input)
• I = Informed (Role kept updated on progress)

---

5. Step-by-Step Procedure

Phase 1: Preparation & Information Gathering

• 1.1 Retrieve the approved Project Mandate from the Enterprise PMIS repository.
• 1.2 Identify and catalog the Executive, Senior User(s), and Senior Supplier(s) to form the Project Board.
• 1.3 Schedule the Project Brief scoping workshop with key stakeholder representatives.

Phase 2: Drafting the Project Brief Components

• 2.1 Define the Project Definition & Scope: Author the project objectives, desired outcomes, and explicit out-of-scope parameters to prevent scope creep.
• 2.2 Construct the Outline Business Case: Document the strategic driver, financial investment appraisal, cost-benefit analysis, and expected return on investment (ROI).
• 2.3 Establish the Project Product Description (PPD): Specify the final deliverable(s), acceptance criteria, and quality expectations required by the customer.
• 2.4 Map the Project Management Team Structure: Populate the organizational chart detailing reporting lines for the Project Board, Project Manager, Team Managers, and Assurance roles.
• 2.5 Draft Initial Tolerances: Define baseline tolerances across the six PRINCE2 variables: Time, Cost, Quality, Scope, Benefit, and Risk.

Phase 3: Risk Assessment & Tailoring

• 3.1 Initialize the Project Risk Register by extracting enterprise-level threats and opportunities relevant to the mandate.
• 3.2 Document initial assumptions and external dependencies that could impact project viability.
• 3.3 Tailor the PRINCE2 Project Brief template to match the scale, complexity, and risk profile of the specific initiative.

Phase 4: Review, Submission & Baselining

• 4.1 Submit the completed Project Brief draft to Quality Assurance for structural and methodological compliance auditing.
• 4.2 Incorporate QA feedback and secure formal sign-off from the Project Sponsor.
• 4.3 Present the Project Brief to the Project Board for authorization to initiate the Initiating a Project (IP) process.
• 4.4 Archive the baselined document in the institutional Document Management System (DMS) under configuration management control.

---

6. Quality Assurance & Pro-Tips

Best Practices (Pro-Tips)

• Never omit the "Out of Scope" section: Clearly stating what the project will not do is statistically the most effective countermeasure against scope creep.
• Keep the Business Case dynamic: Treat the Outline Business Case as a living hypothesis that will be refined during the Initiating stage into the Detailed Business Case.

Common Pitfalls to Avoid

• Vague Acceptance Criteria: Avoid subjective statements like "system must be fast." Use quantitative metrics such as "system API response time must not exceed 200ms under a 500-user concurrent load."
• Confusing Roles: Do not assign the Project Manager role to the Project Executive; maintaining separation of duties is critical for governance integrity.

Metric Thresholds

• Review Cycle Time: The time elapsed from Phase 1.1 to Phase 4.3 must not exceed ten (10) business days unless formally extended by the Chief Architect.
• Compliance Score: Audited Project Briefs must achieve $\ge 95%$ adherence to the Template Registry PRINCE2 schema checklist.

---

7. Frequently Asked Questions (FAQ)

Q1: What is the primary difference between a Project Mandate and the Project Brief?
A: The Project Mandate is the external trigger document (often a 1-2 page memo) that arrives before the project exists, prompting its exploration. The Project Brief is the formalized output of the PRINCE2 Starting up a Project (SU) process that synthesizes this mandate into a structured proposal ready for Board evaluation.

Q2: Can tolerances in the Project Brief be modified after Board approval?
A: Yes, but only through formal Exception Management protocols. Once baselined, any shift in Time, Cost, Quality, Scope, Benefit, or Risk tolerances requires an Exception Report submitted to the Project Board for re-authorization.