Purpose
This SOP establishes a lightweight, repeatable process to create and approve a Project Charter at Memorres. The charter is the single source of truth that defines why a project exists, what success looks like, who is accountable, and which guardrails must be respected. In a lean environment, delays and ambiguity often stem from unclear objectives, informal scope boundaries, and undocumented decision rights. This document provides a disciplined path—from inputs to approvals—so project managers can mobilize teams quickly while protecting schedule, scope, and budget. The SOP emphasizes evidence over verbosity: every section of the charter has a clear owner, minimum data fields, quality criteria, and an approval route. When followed, work starts only after success criteria, constraints, and authorities are explicit, reducing downstream change friction and enabling predictable reporting from day one.
Scope
This SOP applies to all client and internal projects initiated under the Memorres PM lifecycle, regardless of size or contract type. It governs the creation, review, approval, and version control of the Project Charter, including the minimum fields required, source inputs, stakeholder engagement for validation, and the decision record for sign-off. Delivery methodologies and discipline-specific plans are excluded; the charter remains a PM artifact that frames outcomes, boundaries, governance, and high-level timelines. Small projects may compress meetings and combine approvals but must retain all mandatory fields and a signed decision log entry. Where client governance is stricter, the stricter rule supersedes. Any deviation from this SOP requires a documented exception approved by the sponsor and PM lead.
Definitions
Project Charter – The approved document that authorizes the project, names the PM, and sets objectives, success criteria, boundaries, and authority.
Sponsor – Executive accountable for business outcomes and final approvals.
Baseline – Approved reference for scope and schedule used for future control.
Main Section — Charter Creation & Approval Process
Roles & Responsibilities (RACI)
| Activity | PM | Sponsor | Delivery Leads | Finance | PM Lead/PMO |
| Gather inputs & draft charter | R | C | C | C | I |
| Validate objectives, scope boundaries, success criteria | R | A | C | I | I |
| Review risks, assumptions, constraints | R | C | C | I | I |
| Confirm governance, approvals, and cadence | R | A | C | I | C |
| Approve charter and authorize project | I | A | C | C | C |
| Record decision and publish in MIC | R | I | I | I | I |
Charter Minimum Data Structure
| Section | Required Fields | Source Inputs | Acceptance Criteria |
| Project Overview | Business need, objectives, in/out of scope summary, success criteria | Intake brief, discovery notes | Objectives are measurable; success criteria testable and time-bound |
| Authority & Governance | Named sponsor, named PM, decision rights, escalation path, approval matrix | Org map, policy | Decision rights mapped to scope/schedule/budget; escalation timeframes defined |
| Deliverables & Scope | High-level deliverables, explicit out-of-scope list, acceptance at release level | Workshops, prior SOW | Deliverables tied to objectives; exclusions unambiguous |
| High-Level Timeline | Milestones, target dates, critical assumptions | Rough plan, capacity calendars | Dates feasible with stated assumptions; early risks identified |
| Constraints & Assumptions | Technical, legal, budgetary, resource constraints; key assumptions | Contracts, compliance notes | Constraints are explicit; assumptions testable at gates |
| Risks & Dependencies | Top risks, external dependencies, initial responses | Risk brainstorm, vendor inputs | Risks scored; owners named; first responses documented |
| Communication Cadence | Forums, frequency, audiences, artifacts, decision logging rule | Internal cadences | Weekly review defined; decision log within 24h mandated |
| Budget/Effort Envelope | Initial spend or effort cap, funding owner | Finance sheet, SOW | Envelope stated with tolerance bands and approval trigger |
| Approval Record | Sign-off names, dates, version, MIC link | Governance policy | All approvers captured; MIC link published |
Creation Workflow & Quality Gates
| Step | Inputs | PM Activities | Outputs | Gate & Criteria |
| 1. Intake & Framing | Intake brief, sponsor intent | Confirm business need; agree measurable objectives and success criteria draft | Objectives & success criteria v1 | Proceed when sponsor agrees objectives are outcome-based and testable |
| 2. Boundary Setting | SOW, discovery notes | Draft deliverables and out-of-scope; capture constraints and assumptions | Scope section v1 | Proceed when exclusions are explicit and constraints listed |
| 3. Timeline Sketch | Capacity, calendars | Identify milestones and target dates; note critical assumptions and risks | Milestone plan v1 | Proceed when dates align with capacity and risk hotspots flagged |
| 4. Governance Design | Policy, org map | Fill decision rights, escalation ladder, approval matrix, cadences | Governance section v1 | Proceed when approvers and cadences are named and timed |
| 5. Risk & Dependency Pass | Risk brainstorm | Score top risks; assign owners; log external dependencies | Risk list v1 | Proceed when each risk has owner and initial response |
| 6. Fiscal Envelope | Finance inputs | Capture spend/effort envelope and tolerance bands; approval triggers | Budget/effort section v1 | Proceed when tolerance and triggers are explicit |
| 7. Internal Review | Draft charter | Circulate to leads and finance for factual checks | Draft v2 | Proceed when no material gaps remain |
| 8. Sponsor Review & Approval | Draft v2 | Walkthrough; agree final edits; record sign-off | Approved Charter v1.0 | Proceed when sponsor signs and PM publishes in MIC |
Quality Checklist (Pass/Fail at Approval)
| Criterion | Test | Evidence |
| Objectives are measurable | Each objective has a quantifiable target and timeframe | “Reduce onboarding time by 30% by Q2” |
| Success criteria are testable | Criteria map to acceptance events | “UAT sign-off on three modules” |
| Scope boundaries are clear | Out-of-scope items are explicit | “No legacy data migration in Phase 1” |
| Governance is actionable | Decision rights and escalation SLAs present | Matrix plus 24h decision-log rule |
| Timeline is credible | Milestones aligned to capacity and assumptions | Dates cross-checked with calendars |
| Risks have owners | Each top risk has owner and first response | Risk register excerpt |
| Budget/effort has controls | Tolerance bands and triggers defined | “>5% variance → CCB” |
| Publication complete | MIC link and version recorded in status report | URL in Decision Log and Status Report |
Approval Workflow & SLAs
| Stage | Approvers | SLA | Notes |
| Internal factual review | Delivery Leads, Finance | 2 working days | Focus on scope realism and fiscal envelope |
| Executive approval | Sponsor | 2 working days | One pass; unresolved items converted to risks or CR at planning |
| Publication | PM | Same day | MIC upload and decision-log entry within 24 hours |
Versioning & Change Control
| Event | Version Rule | Ownership | Record |
| Initial approval | v1.0 | PM | Decision Log + MIC permalink |
| Minor clarification (no baseline impact) | v1.x | PM | Note in change summary; notify stakeholders |
| Material change to scope/timeline/budget | v2.0+ | PM via CCB | Formal CR; updated approval record |
Closing Note & Cross-References
This SOP ensures every project begins with an authorized, testable mandate and clear authority lines. The charter anchors later baselines and accelerates decision-making by removing ambiguity before planning work starts. Use this SOP with the Project Governance & Accountability Policy for decision rights, the Stakeholder Register Template and Communication Plan Template for cadence setup, the Schedule Development & Baseline SOP for timeline formalization, and the Change Request & Scope Control Policy for material updates post-approval. The approved charter’s MIC link must appear in the first Weekly Status Report (RAG + Forecast), and any clarifications must follow the versioning and change-control rules above.