Good to see you again. In the previous lesson, you established baselines and measurable acceptance criteria: the evidence needed to decide whether an analytics initiative is ready to pilot, scale, or stop. This lesson turns that material into a document stakeholders can actually use.
A one-page project charter is the compact agreement that connects the business decision, technical work, operating workflow, risks, and ownership. It is especially important for analytics work because a request such as “build a churn model” can conceal unresolved questions: Who will use it? What will they decide differently? Which data are permitted? What is explicitly out of scope? What evidence would justify scale-up?
By the end of this lesson, you will be able to write a concise charter that frames a technical initiative in stakeholder terms, without pretending that uncertain modelling work has a fixed delivery plan.
The charter is an alignment document, not a project plan
A project charter records the why, what, boundaries, authority, and decision criteria for an initiative. It gives a sponsor enough clarity to authorize work and gives the delivery team enough protection against scope drift.
A project plan serves a different purpose. It contains the detailed tasks, estimates, dependencies, sprint commitments, and working schedule that emerge once the project is authorized. A charter may name a few high-level milestones, but it should not become a miniature Gantt chart or a detailed technical design.
How to Write a Project Charter: Template & Example | TeamGantt
Watch How to Write a Project Charter: Template & Example from TeamGantt for a concise overview of what a charter is, how it differs from a project plan, and which elements commonly belong in it.
Start with charter purpose to see the charter as an authorization and alignment document. Then watch charter versus plan, focusing on the distinction between the high-level purpose of a charter and the detailed execution plan. Finally, watch stakeholder input and charter components. Notice that objectives, scope, resources, milestones, risks, dependencies, and decision-makers are all included, but granular tasks are not.
For a data or analytics initiative, the charter’s central question is:
What decision will be improved, for whom, under what constraints, and what evidence will justify continuing?
That phrasing prevents a frequent failure mode: treating the model, dashboard, or pipeline as the project’s objective. These are deliverables. The objective is a better operational or business decision.
For example, compare these two project descriptions:
| Weak technical framing | Decision-centred charter framing |
|---|---|
| “Build a churn prediction model.” | “Enable retention specialists to prioritize up to 300 eligible accounts each weekday, with the aim of improving 60-day retention without increasing customer complaints or opt-outs.” |
| “Create a sales dashboard.” | “Give regional sales managers a shared weekly view of pipeline coverage and conversion bottlenecks so they can redirect account-support capacity.” |
| “Use AI to automate support.” | “Help support agents classify incoming requests consistently and route urgent cases within the agreed response-time target; the system will not autonomously send customer responses during the pilot.” |
The second column gives stakeholders something concrete to approve or challenge. It identifies the user, decision, capacity constraint, expected value, and an important boundary.
What must fit on one page
“One page” is not merely a formatting preference. It imposes discipline. If a statement cannot be expressed concisely, it may not yet be agreed, measurable, or sufficiently understood.
The exact template varies by organisation, but a practical analytics charter usually has seven compact components:
-
Identity and authority
Project title, sponsor, accountable product or business owner, delivery lead, date, and version. -
Business case and decision
The problem or opportunity, the intended user, the decision they will make, and why the decision matters. -
Scope and deliverables
What will be produced in this initiative, what is explicitly excluded, and how the output enters a workflow. -
Success criteria and gates
The baseline, acceptance criteria, guardrails, and the people who decide whether the initiative proceeds. -
Data, technical, and governance constraints
Relevant sources, latency needs, security and privacy conditions, and constraints such as human review or explainability. -
Risks, dependencies, and assumptions
The conditions that could invalidate the work or delay delivery, along with the intended response. -
Stakeholders and decision rights
The people affected, their responsibilities, and who has final authority when a material trade-off is required.
The Data Science PM checklist is a useful reference because it treats problem definition, metrics, anti-goals, stakeholders, consumption, resources, and risk as connected elements rather than separate administrative tasks.
The Data Science Project Checklist - Data Science PM
Read the selected sections of The Data Science Project Checklist from Data Science PM to see how a data-science project can be framed around a business problem, stakeholder needs, deliverables, constraints, and risks before substantial modelling begins.
In Section 1, “Define a Clear Problem or Opportunity,” read the problem, goals, and stakeholder guidance. Focus on the distinction between the presenting request and the underlying need, and on anti-goals as a way to make scope visible. Then move to Section 2, “Define the Solution.” Read the deliverable and consumption discussion. Pay particular attention to the difference between deployment and actual consumption: publishing a model output does not mean users receive, understand, or act on it. In Section 3, “Define the Approach,” read the resources and risk material. Use it as a prompt for the charter’s concise resource, dependency, data, privacy, and risk statements rather than as a request to create a comprehensive project plan.
The project-charter template below shows the common fields visually. It is a useful starting layout, but the quality of a charter comes from the decisions inside each field, not from completing every box mechanically.
What to write, and what to leave out
The most productive way to keep a charter short is to distinguish charter-level commitments from delivery-level detail.
| Include in the charter | Put in linked working documents instead |
|---|---|
| Decision, users, business rationale, and intended outcome | Full requirements specification |
| In-scope population, channels, geography, and deliverables | Column-level data dictionary |
| Major data sources and governance constraints | Feature-engineering logic |
| Baselines, acceptance criteria, and guardrails | Full experiment-analysis notebook |
| Major dependencies, risks, and mitigations | Complete risk register |
| Named owners and decision rights | Sprint board and task assignments |
| Milestone gates and target windows | Detailed project schedule |
| Budget range or resource commitment, if material | Line-item cost model |
This distinction is valuable when leading a hands-on team. A sponsor should be able to read the charter in a few minutes and understand the trade-offs they are accepting. A data scientist should be able to trace every proposed technical choice back to a stated decision, constraint, or success criterion.
Write each section as an operational agreement
A charter needs precise statements, not ceremonial language. The following patterns make that easier.
1. Business case: state the decision, not the technology
A concise business case has four parts:
[User or team] needs to make [decision] for [unit of analysis] at [decision frequency or moment] in order to improve [business outcome].
For the running retention example:
Retention specialists need to prioritize which eligible customer accounts to contact each weekday morning, within a capacity of 300 accounts per day, in order to improve 60-day customer retention.
This is stronger than “reduce churn.” It tells the team that the output needs to be a daily, capacity-aware ranking, not a monthly executive dashboard or an individual customer-facing prediction.
If there is a financial case, state it as an estimate with assumptions, rather than a promise:
A 3-percentage-point retention improvement among the pilot population is estimated to retain approximately contribution margin per quarter, assuming current average account value and no increase in outreach cost beyond the pilot staffing plan.
Use a range when inputs are uncertain. Early analytics projects benefit from transparent assumptions more than from false precision.
2. Scope: give the initiative a boundary
A charter’s scope section should make it easy to answer: “Does this new request belong in this project?”
Use both in scope and out of scope. The latter is often more important.
| In scope | Out of scope |
|---|---|
| Eligible German customer accounts covered by the pilot | Customers without an approved contact basis |
| Daily batch ranking in the existing CRM workflow | Real-time scoring or a public-facing application |
| Pilot evaluation against the current rule-based queue | Fully automated customer outreach |
| Specialist action and approved override capture | Replacing retention-offer policy or pricing decisions |
Scope is not an apology for doing less. It is the mechanism that makes learning possible. A well-scoped pilot can demonstrate whether model-supported prioritization creates value before the organisation funds a wider platform or changes a sensitive customer interaction.
3. Deliverables: specify the usable product
Avoid listing “model” as the sole deliverable. The user needs a usable decision product.
A compact deliverables statement might be:
Pilot deliverables: daily ranked CRM queue of up to 300 eligible accounts; documented fallback to the current rule-based queue; reproducible evaluation report; pilot dashboard covering usage, customer outcomes, and guardrails; scale, revise, or stop recommendation.
Notice the inclusion of a fallback and a decision recommendation. Both are essential to stakeholder expectations. A model may be unavailable, and a pilot may produce evidence against scale-up. Neither outcome should be treated as a surprise.
4. Success criteria: reference the gates already agreed
From the previous lesson, you have a baseline and acceptance criteria. Do not repeat their full rationale in the charter. State the small number of conditions that govern decisions.
For example:
- Technical pilot gate: On the held-out evaluation period, the model identifies at least 10% more eventual churners in the daily top 300 than the current rule.
- Operational pilot gate: The CRM queue is available by 07:30 CET on at least 95% of pilot weekdays; the current rule-based queue is available after any failed model run.
- Business scale gate: Estimated 60-day retention is at least 3 percentage points higher than the pre-specified comparison workflow.
- Guardrails: Complaint and opt-out rates do not exceed the comparison workflow by more than 0.2 percentage points; agreed segment results are reviewed before scale.
Include the decision owner. A delivery lead can produce the evidence; they should not unilaterally decide whether business risk is acceptable.
5. Constraints, dependencies, and risks: distinguish the three
These terms are often blended together, but they have different implications:
| Item | Meaning | Example |
|---|---|---|
| Constraint | A non-negotiable condition of the solution | Only approved first-party account, billing, and contact-preference data may be used. |
| Dependency | An external condition needed for progress | CRM access and the approved production service account are required before pilot launch. |
| Risk | An uncertain event that could affect value, timing, or safety | The available history may not contain sufficient predictive signal for a useful ranking. |
| Assumption | A condition treated as true for planning, but needing validation | Retention specialists will have capacity to contact about 300 accounts daily. |
For each significant risk, write a brief mitigation or decision response:
Risk: Current data may not improve upon the existing rule.
Response: Conduct feasibility analysis and held-out evaluation before CRM integration; if the uplift threshold is not met, stop model development and recommend data collection or process redesign.
A risk without an owner or response is merely a concern recorded for later.
Stakeholders: move from a name list to decision rights
A stakeholder list alone does not create alignment. Different stakeholders need different information, can block different parts of the work, and may define “success” differently.
For example, the Retention Director may care primarily about retention and staff capacity. The privacy or legal reviewer may focus on the lawful and appropriate use of data. A CRM owner may care about reliability and operational support. Specialists need a queue they can understand and act upon without creating extra administrative work.
What is a Stakeholder Analysis? — Leading Successful Projects
Watch the selected part of What is a Stakeholder Analysis? — Leading Successful Projects from ProductPlan for a practical way to identify, prioritize, and understand stakeholders before writing their roles into the charter.
Watch identify stakeholders for the starting point: include people and groups materially affected by the initiative, not only senior sponsors. Then watch power and interest to distinguish stakeholders who need active decision involvement from those who mainly require visibility. Finish with stakeholder motivations, focusing on the questions each stakeholder profile should answer about incentives, competing priorities, and possible resistance.
For a small initiative, a stakeholder section can remain compact:
| Role | Charter responsibility and expectation |
|---|---|
| Executive sponsor | Owns business case and funding; approves pilot and scale decisions. |
| Retention Director | Owns operational adoption, specialist capacity, and customer-outcome trade-offs. |
| Product Owner | Owns workflow requirements, backlog prioritization, and final pilot experience. |
| Analytics Lead | Owns evaluation design, reproducible analysis, model recommendation, and transparent limitations. |
| Data Engineering Lead | Owns secure, reliable data preparation and CRM publication mechanism. |
| Privacy / Legal reviewer | Confirms that intended data use and retention are appropriate before pilot launch. |
| Retention specialists | Use the queue, record actions or approved overrides, and provide feedback on workflow quality. |
The exact job titles will differ across organisations. What matters is that each role has a clear decision or accountability, rather than a vague instruction to “collaborate.”
A practical rule: one role must have the final decision for each material issue. Consultation can be broad; accountability cannot be.
A worked one-page charter
The following example consolidates the decisions developed across this module. In a document editor, it would be formatted in two columns with short bullets and compact tables; it is shown in a linear format here for readability.
Project Charter — Retention Prioritization Pilot, Germany
| Field | Charter statement |
|---|---|
| Sponsor and accountable owners | Sponsor: Retention Director. Business owner: Head of Customer Retention. Product owner: CRM Product Manager. Delivery lead: Analytics Lead. Version/date: v0.1, 15 May 2025. |
| Business case and decision | Retention specialists need to prioritize eligible accounts for outreach each weekday morning, within a capacity of 300 accounts per day. The pilot tests whether a model-supported queue can improve 60-day retention relative to the current rule-based prioritization, while maintaining customer-protection and operational standards. |
| Baseline | On a held-out historical period, 24% of accounts in the current rule’s daily top 300 churn within 60 days. The existing queue is available by 07:30 CET on 85% of working days. The current workflow retains 62% of eligible accounts after 60 days; this descriptive figure does not establish intervention impact. |
| In scope | Eligible German accounts with approved contact basis; daily batch ranking; CRM queue publication; action and override capture; a controlled or otherwise pre-specified pilot comparison; pilot evaluation. |
| Out of scope | Automated customer communications; offer or pricing policy; real-time scoring; customer eligibility-policy changes; use of external data; expansion outside the German pilot population. |
| Pilot deliverables | Daily ranked CRM queue for up to 300 accounts; documented fallback to the existing queue; reproducible evaluation report; monitoring dashboard for availability, use, primary outcome, and guardrails; final scale, revise, or stop recommendation. |
| Success criteria and gates | Technical: At least 10% more eventual churners in the daily top 300 than the current rule on the held-out evaluation period. Operational: Queue is published by 07:30 CET on at least 95% of pilot weekdays; fallback is available for all failed runs. Adoption: Specialists record an action or approved override for at least 90% of recommendations. Scale: Estimated 60-day retention is at least 3 percentage points higher than the pre-specified comparison workflow. Guardrails: Complaint and opt-out rates do not exceed the comparator by more than 0.2 percentage points; agreed segment results are reviewed. |
| Data and governance constraints | Use only approved first-party account, billing, service-interaction, and contact-preference data. Exclude prohibited fields and minimize data to what is necessary for the stated purpose. Apply role-based access, documented retention, and privacy review before pilot launch. The output supports specialist judgment; it does not automate customer action. |
| Key dependencies and risks | Dependencies: CRM integration access, data-owner support, privacy approval, specialist capacity. Risks: insufficient predictive signal, late data feeds, inappropriate outreach, low user trust, or unequal performance across relevant segments. Responses: feasibility gate before integration; rule-based fallback; specialist override reasons; monitored guardrails and segment review. |
| Milestone gates | Data and governance feasibility review; offline technical evaluation; pilot-readiness review; four-week operational pilot; 60-day outcome evaluation; sponsor scale, revise, or stop decision. Target dates are maintained in the linked delivery plan. |
| Decision rights and sign-off | Analytics Lead recommends technical readiness. Product Owner confirms workflow readiness. Privacy / Legal reviewer approves intended data use before pilot. Retention Director, informed by the Sponsor, decides whether to launch and scale. |
This charter is deliberately not a promise that the model will work. It commits the organisation to a bounded, evidence-producing initiative. It also makes several otherwise hidden trade-offs visible:
- The project is not allowed to compensate for weak predictive performance by expanding outreach indiscriminately.
- The delivery team cannot claim success from an offline metric alone.
- The business cannot demand a pilot without making specialist capacity, CRM access, and a comparison approach available.
- The sponsor retains the decision to scale because scaling involves business, customer, and governance risk beyond model performance.
That is what alignment looks like in practice: the technical team knows what it must demonstrate, and stakeholders know what they must provide and decide.
A reliable drafting sequence
When drafting a charter for a real initiative, do not begin with a blank template. Start with the artefacts already created in this module, then compress them.
- Write the decision statement from the user, target, unit of analysis, and time horizon.
- Select the one primary outcome and the few supporting acceptance gates that determine pilot and scale decisions.
- State the in-scope population and workflow, then write the out-of-scope list.
- Name the usable deliverables, including fallback and evaluation output.
- Add the critical data, privacy, latency, and fairness constraints.
- Identify the stakeholders who own the decision, workflow, data, technical delivery, and governance review.
- Record only the dependencies and risks that could materially change the decision, scope, or timeline.
- Remove implementation detail until the document fits on one page without losing a decision-critical fact.
The following final check is often more useful than proofreading for grammar:
| Charter test | What it reveals |
|---|---|
| Could a sponsor explain the initiative’s purpose in two sentences? | The business case is clear. |
| Could a user describe what they will do differently? | The output is connected to a real workflow. |
| Could the team reject a new request by pointing to scope? | Boundaries are meaningful. |
| Could an independent reviewer determine whether pilot criteria were met? | Success measures are testable. |
| Could each major trade-off be traced to an accountable decision-maker? | Stakeholder expectations are aligned. |
| Could the team stop or revise the project without calling it a failure? | The charter treats uncertainty honestly. |
Key takeaways
A one-page project charter is a decision-centred agreement, not a compressed technical specification or delivery schedule.
- Start with the user’s decision and business outcome, not the model, dashboard, or cloud platform.
- State scope and anti-goals explicitly so that the pilot remains learnable and manageable.
- Include a small set of prior-agreed baselines, acceptance criteria, and guardrails that govern pilot and scale decisions.
- Specify deliverables in terms of how they are consumed in a workflow, including fallback behavior.
- Make data, privacy, reliability, fairness, dependencies, and risks visible early.
- Name stakeholder responsibilities and decision rights, especially the person accountable for launch and scale decisions.
- Keep uncertain work honest: use milestone gates and assumptions instead of presenting speculative technical results as commitments.
Next, you will use this charter as the foundation for a five-minute executive presentation, where the challenge is not adding technical detail but defending the scope, evidence gates, and trade-offs clearly under questioning.
Can't find a good explanation? Sign up and we'll make it for you
Sign up