Project Charter Example for Students

Standard Operating Procedure: Project Charter Construction for Academic Engineering Design

---

1. Executive Summary & Purpose

1.1 Objective

This Standard Operating Procedure (SOP) defines the mandatory methodology for authoring, reviewing, and baselining a Project Charter within academic engineering environments. The charter serves as the immutable contract between the student engineering team, faculty advisors, and external stakeholders.

1.2 Purpose

Ambiguity is the primary vector of project failure. This procedure operationalizes requirements gathering, scope bounding, and risk mitigation into a deterministic workflow, ensuring student teams achieve architectural alignment before committing compute or capital resources.

---

2. Scope & Prerequisites

2.1 Scope

This SOP applies to all student design teams operating under the Template Registry engineering curriculum, spanning capstone projects, research prototypes, and systems integration exercises.

2.2 Prerequisites & Tooling

• Access Control: Write permissions to the institutional version control repository (GitHub/GitLab).
• Collaboration Suite: Markdown-compatible text editor (VS Code, Obsidian) and LaTeX/pandoc for PDF compilation.
• Artifacts Required: Sponsor statement of work (SoW), preliminary bill of materials (BoM) template, and risk assessment matrix.
• PPE/Safety: Not applicable for document drafting; mandatory lab-specific PPE applies downstream during execution phases.

---

3. Roles & Responsibilities

---

4. Step-by-Step Procedure

Phase 1: Problem Definition & Executive Summary

• 1.1 Extract the core problem statement from the Sponsor Statement of Work (SoW), limiting the text to a maximum of 3 sentences.
• 1.2 Define the primary engineering objective using SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound).
• 1.3 Draft the high-level system overview diagram and embed it in the charter's asset directory.

Phase 2: Scope Boundary Determination

• 2.1 Enumerate explicit In-Scope deliverables (e.g., prototype PCB v1.0, containerized microservice, physical chassis).
• 2.2 Enumerate explicit Out-of-Scope assumptions to prevent scope creep (e.g., mass manufacturing tooling, commercial cloud deployment).
• 2.3 Establish acceptance criteria for each in-scope deliverable, tying them directly to quantitative test metrics.

Phase 3: Stakeholder & Milestone Mapping

• 3.1 Populate the RACI matrix mapping team members to subsystems (Power, Compute, Interface, Structural).
• 3.2 Define high-level project milestones with hard calendar deadlines (e.g., PDR, CDR, TRR, Final Demo).
• 3.3 Link milestones to verifiable artifacts (Schematics, Test Reports, Source Code Tags).

Phase 4: Risk Registry Initialization

• 4.1 Identify top 5 technical and operational risks (e.g., supply chain latency, thermal throttling).
• 4.2 Score each risk using the $Impact \times Likelihood$ matrix (Scale 1–5).
• 4.3 Formulate proactive mitigation strategies and assign an accountable subsystem owner for each risk.

---

5. Quality Assurance & Pro-Tips

5.1 Best Practices

• Treat the Charter as Immutable Code: Once baselined (v1.0), any modification to scope requires a formal Engineering Change Order (ECO) signed by the Faculty Advisor.
• Quantify Everything: Avoid qualitative adjectives (e.g., "fast," "lightweight"). Use strict metrics (e.g., "Latency $< 50\text{ms}$," "Mass $< 1.5\text{kg}$").

5.2 Common Pitfalls

• Vague Boundaries: Failing to document out-of-scope items, resulting in unmanageable feature bloat.
• Orphaned Metrics: Defining performance requirements that cannot be verified with available laboratory instrumentation.

5.3 Metric Thresholds

• Completeness Check: 100% of checklist items in Section 4 must be checked before submission.
• Review Latency: Faculty advisory review must be completed within 5 business days of submission.

---

6. Frequently Asked Questions (FAQ)

Q1: What should we do if the project sponsor requests a scope change after the charter is baselined?
A1: You must issue an Engineering Change Request (ECR) document detailing the impact on schedule, budget, and performance metrics. The Faculty Advisor and Sponsor must sign the ECR before work on the new scope begins.

Q2: How granular should the milestone schedule be within the charter?
A2: The charter should maintain high-level programmatic milestones (phase gates). Detailed task-level tracking (e.g., daily Scrum boards, Jira epics) should be maintained in the project management tracking tool referenced by the charter, not within the static document.