Appendix A: The Legal Project Management (LPM) Project Charter Template
A ready-to-use project charter template for Legal Operations initiatives — from CLM deployments to process re-engineering projects.
Purpose
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
| Field | Description |
|---|---|
| Project Name | [Descriptive name, e.g., "CLM Implementation — Phase 1"] |
| Project Sponsor | [Name and title of the executive sponsor, typically GC or CLO] |
| Project Lead | [Name and title of the Legal Ops lead responsible for delivery] |
| Date Initiated | [DD/MM/YYYY] |
| Target Completion | [DD/MM/YYYY] |
| Version | [Charter version number] |
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 | Success Metric | Target | Measurement Method |
|---|---|---|---|
| [Objective 1] | [Specific, measurable metric] | [Quantified target] | [How it will be measured] |
| [Objective 2] | [Specific, measurable metric] | [Quantified target] | [How it will be measured] |
| [Objective 3] | [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
| Stakeholder | Role | Responsibility | Time Commitment |
|---|---|---|---|
| [Name] | Project Sponsor | Strategic direction, budget approval, escalation resolution | 2 hrs/month |
| [Name] | Project Lead | Day-to-day management, delivery accountability | [X] hrs/week |
| [Name] | Business SME | Requirements input, UAT, adoption champion | [X] hrs/week |
| [Name] | IT/Technology | Integration, security review, infrastructure | [X] hrs/week |
| [Name] | Vendor PM | Platform configuration, training, support | Per SOW |
6. Timeline and Milestones
| Phase | Milestone | Target Date | Dependencies |
|---|---|---|---|
| Discovery | Requirements document approved | [Date] | Stakeholder interviews complete |
| Design | Process maps and system design approved | [Date] | Requirements approval |
| Build | System configured and integration tested | [Date] | Design approval, IT resources available |
| Test | UAT complete, issues resolved | [Date] | Build complete |
| Launch | Go-live with pilot group | [Date] | UAT sign-off |
| Stabilise | Full rollout, training complete | [Date] | Pilot success confirmed |
7. Budget
| Category | Estimated Cost | Approval Status |
|---|---|---|
| Technology licensing (Year 1) | $[Amount] | [Approved/Pending] |
| Implementation services | $[Amount] | [Approved/Pending] |
| Internal resource allocation | $[Amount / FTE equivalent] | [Approved/Pending] |
| Training and change management | $[Amount] | [Approved/Pending] |
| Contingency (10-15%) | $[Amount] | [Approved/Pending] |
| Total | $[Amount] |
8. Risks and Mitigations
| Risk | Probability | Impact | 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"] |
| [Risk 2, e.g., "Data quality insufficient"] | [H/M/L] | [H/M/L] | [Specific mitigation] |
| [Risk 3, e.g., "Vendor delivery delay"] | [H/M/L] | [H/M/L] | [Specific mitigation] |
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
| Role | Name | Signature | Date |
|---|---|---|---|
| Project Sponsor | |||
| Project Lead | |||
| IT Approver | |||
| Finance Approver |
Strategic Insight
The charter serves as insurance for your project. It prevents scope drift, maintains stakeholder alignment, and establishes clear success criteria from the start. The 2-3 hours invested in completing the charter saves weeks of rework and misalignment downstream.
Chapter 16: The Australasian Paradigm — A Compliance Stress-Test
The 2026 Tranche 2 AML/CTF deadline, re-engineering client intake for CDD and UBO verification, the LPP battleground, and addressing the digital self-sufficiency gap in lean legal structures.
Appendix B: The Legal Tech Vendor RFP Matrix & 'AI-Ready' Scorecard
A structured evaluation framework for legal technology procurement — weighted scoring criteria, the AI-readiness assessment, and a template RFP structure.