Appendix A: The Legal Project Management (LPM) Project Charter Template
The LPM Project Charter is the foundational document for any Legal Operations initiative. It defines the scope, objectives, stakeholders, timeline, and success criteria before work begins. No Legal Ops project should proceed past the planning phase without an approved charter.
The Charter Template
1. Project Overview
| Target Completion | [DD/MM/YYYY] |
|---|---|
| Field | Description |
| Version | [Charter version number] |
| Project Name | [Descriptive name, e.g., “CLM Implementation — Phase 1”] |
| Project Lead | [Name and title of the Legal Ops lead responsible for delivery] |
| Date Initiated | [DD/MM/YYYY] |
| Project Sponsor | [Name and title of the executive sponsor, typically GC or CLO] |
2. Problem Statement
In 2-3 sentences, describe the specific business problem this project addresses. Use quantified data where possible.
Template: “The [department/function] currently [describe current state with data]. This results in [quantified impact: cost, time, risk]. This project will [describe the change] to achieve [quantified target outcome].”
Example: “The legal department currently processes 1,200 contracts per year through a manual, email-based workflow with an average cycle time of 34 business days. This results in approximately $1.8M in delayed revenue recognition annually. This project will implement a CLM platform with digital playbooks to reduce average cycle time to 18 business days.”
3. Objectives and Success Criteria
| [Objective 1] | [Specific, measurable metric] | [Quantified target] | [How it will be measured] |
|---|---|---|---|
| [Objective 3] | [Specific, measurable metric] | [Quantified target] | [How it will be measured] |
| Objective | Success Metric | Target | Measurement Method |
| [Objective 2] | [Specific, measurable metric] | [Quantified target] | [How it will be measured] |
4. Scope
In Scope:
- [Specific deliverable or work stream 1]
- [Specific deliverable or work stream 2]
- [Specific deliverable or work stream 3]
Out of Scope:
- [Explicitly excluded item 1 — with rationale]
- [Explicitly excluded item 2 — with rationale]
Scope Change Process: Any change to the defined scope requires written approval from the Project Sponsor. Scope changes will be assessed for impact on timeline, budget, and resource requirements before approval.
5. Stakeholders
| [Name] | Vendor PM | Platform configuration, training, support | Per SOW |
|---|---|---|---|
| [Name] | Project Sponsor | Strategic direction, budget approval, escalation resolution | 2 hrs/month |
| [Name] | IT/Technology | Integration, security review, infrastructure | [X] hrs/week |
| [Name] | Project Lead | Day-to-day management, delivery accountability | [X] hrs/week |
| [Name] | Business SME | Requirements input, UAT, adoption champion | [X] hrs/week |
| Stakeholder | Role | Responsibility | Time Commitment |
6. Timeline and Milestones
| Build | System configured and integration tested | [Date] | Design approval, IT resources available |
|---|---|---|---|
| Launch | Go-live with pilot group | [Date] | UAT sign-off |
| Design | Process maps and system design approved | [Date] | Requirements approval |
| Discovery | Requirements document approved | [Date] | Stakeholder interviews complete |
| Test | UAT complete, issues resolved | [Date] | Build complete |
| Stabilise | Full rollout, training complete | [Date] | Pilot success confirmed |
| Phase | Milestone | Target Date | Dependencies |
7. Budget
| Category | Estimated Cost | Approval Status |
|---|---|---|
| Training and change management | $[Amount] | [Approved/Pending] |
| Contingency (10-15%) | \[Amount] | \[Approved/Pending] | | **Total** | **[Amount]** | |
| Implementation services | $[Amount] | [Approved/Pending] |
| Internal resource allocation | $[Amount / FTE equivalent] | [Approved/Pending] |
| Technology licensing (Year 1) | $[Amount] | [Approved/Pending] |
|8. Risks and Mitigations
| [Risk 3, e.g., “Vendor delivery delay”] | [H/M/L] | [H/M/L] | [Specific mitigation] |
|---|---|---|---|
| Risk | Probability | Impact | Mitigation |
| [Risk 2, e.g., “Data quality insufficient”] | [H/M/L] | [H/M/L] | [Specific mitigation] |
| [Risk 1, e.g., “Low user adoption”] | [H/M/L] | [H/M/L] | [Specific mitigation, e.g., “Dedicated change management workstream with WIIFM communications”] |
9. Governance
Reporting cadence: [Weekly/Fortnightly] status reports to Project Sponsor; [Monthly] steering committee updates.
Escalation path: Project Lead → Project Sponsor → [Executive Committee / Board subcommittee, if applicable].
Decision authority: Day-to-day decisions: Project Lead. Budget changes >$[threshold]: Project Sponsor. Scope changes: Project Sponsor with steering committee notification.
10. Approval
| Project Sponsor | |||
| Role | Name | Signature | Date |
| | | ||| Project Lead | | | | | IT Approver | | | | | Finance Approver | | | |
The charter is insurance for your project. It prevents scope drift, maintains stakeholder alignment, and sets clear success criteria from the start. The 2–3 hours spent completing it saves weeks of rework and misalignment downstream.