A useful project charter gives those decisions a boundary. Write what the manager may decide, which resources the project can use, and what must go back to the sponsor. The completed example below applies those terms to two requests that could arrive after planning starts.
Give the project a purpose and a clear edge
This original fictional charter prepares an archive-index pilot for sponsor review. All resources and authority terms are proposed; the example is not an authorization to begin real work.
| Charter field | Worked example |
|---|---|
| Project | Archive-index pilot. |
| Purpose | Prepare a searchable pilot index for two catalog batches so archive staff can review the entries. |
| Deliverable | A reviewable pilot index with references back to the two source batches and a list of unresolved entries. |
| Included work | Inspect the existing catalog material, organize the pilot entries, and prepare the index for staff review. |
| Excluded work | Scanning documents, changing retention policy, and launching a public index. |
| Proposed team and allocation | A project manager coordinates two designated contributors within a combined 24 person-hour planning allocation. Actual names and availability remain to confirm. |
| Milestones | Discovery inventory, followed by a reviewable pilot index. Dates remain to agree. |
| Review condition | The sponsor reviews the pilot and the unresolved-entry list before deciding the next phase. |
The project-charter chapter in Cleveland State University's hosted project-management textbook describes the charter's role in authorizing the project manager to use organizational resources, with sponsor approval. Its example also distinguishes scope, constraints, resources, and approval requirements.
For your own charter, use the approval process and required fields your organization has established. The point of this preparation copy is to make the proposed boundaries understandable before anyone relies on them.
Replace “manage the project” with decisions someone can apply
Choose Compare authority wording in the example. The vague version says:
The project manager will manage the archive-index pilot.
The proposed replacement is more specific:
The project manager may coordinate and resequence the included catalog-review work of the two designated contributors within the combined 24 person-hour planning allocation. The manager may not purchase tools, add scanning work, change retention policy, or authorize public release. Requests beyond these terms go to the sponsor for a decision before the affected work proceeds.
This clause separates coordination from purchasing and publication. It also prevents the planning allocation from being read as 24 hours for each contributor. It is a total allocation for the work described.
Add the actual manager, sponsor, and approval reference when those details exist. A name in a role field identifies a person; it does not show that the proposed authority has been granted.
Test the clause against a request inside the boundary
The first request is:
Review the second catalog batch before the first, while keeping the same work and combined allocation.
Select Resequence review to inspect the relevant wording. The proposed clause explicitly allows resequencing included catalog-review work. Under those terms, the manager could handle the order change without asking for a new equipment budget or changing the deliverable.
For a real request, check that its assumptions still hold. If the order change needs extra time or a different contributor, compare that consequence with the approved resource terms before treating it as routine coordination.
Test a request that needs another decision
The second request is:
Buy scanning equipment and include newly scanned documents in the pilot.
Choose Equipment request. The request crosses two explicit boundaries: purchasing tools and adding scanning work. The manager's coordination clause covers neither.
The preparation copy directs the request to the sponsor. It leaves the actual decision and supporting record blank. A useful escalation states the requested change, why it is needed, and which scope or resource terms would change. If purchasing or another specialist decision is needed, the sponsor can route it through the organization's process.
Do not silently add the request to the charter's included work. Keep the current terms beside the proposed change so the next reader can see what still needs a decision.
Finish the fields that affect delivery
Before presenting your own charter, check the resource assumptions and the review conditions as carefully as the authority clause. For this pilot, the unresolved preparation fields include contributor availability, milestone dates, and the sponsor's review arrangements.
Record a risk where it affects the plan. If catalog entries are incomplete, the pilot may need an unresolved-entry list rather than guessed information. Agree on how that list will be reviewed instead of promising that every entry will be complete.
The example's blank builder lets you organize purpose, scope, deliverable, allocation, authority, and escalation terms. Build review copy identifies missing authority wording. It prepares a discussion page; the organization still records the actual authorization.
Create a charter for your own project
Create one complete, self-contained HTML project-charter review copy.
Project name and purpose: [FILL IN]
Objective and reviewable deliverables: [PASTE]
Included and excluded work: [PASTE]
Manager, sponsor, contributors, and stakeholders: [FILL IN]
Resource and financial terms, with proposed or approved status: [PASTE]
Milestones and dates, leaving unresolved dates blank: [PASTE]
Assumptions, constraints, and significant risks: [PASTE]
Manager's delegated decisions and limits: [PASTE]
Escalation owner and required decision process: [PASTE]
Approval requirements and actual authorization reference, if any: [PASTE]
Two illustrative requests and the clauses relevant to each: [PASTE]
Make the purpose, deliverable, scope, resource terms, and authority
readable together. Keep proposed terms distinct from granted authority.
Compare vague authority wording with a specific proposed revision.
Let a reader select each supplied request to inspect the applicable
clause, boundary, and next decision owner. Explain only the supplied
terms; do not invent approval, spending authority, or resource capacity.
Add a blank review-copy builder and temporary review notes. Identify
missing purpose, scope, allocation, authority, or escalation wording.
Mark an old generated review stale after edits, preserve notes when
switching cases, and ask before resetting typed work. Do not provide
Approve, Spend, Assign, or Publish controls. Do not claim saved decisions.
Use body text of at least 16px, labeled keyboard-accessible controls,
and a layout readable at 360px without horizontal scrolling. Put CSS
and JavaScript inline with no external assets, network, or storage.
Return the complete HTML.
Put the boundary in front of the sponsor
Ask the sponsor to read the two requests alongside the proposed clause. If the sponsor expects a different decision owner, revise the wording before the charter becomes the team's reference.
For an HTML review copy, NOS lets you edit the static authority paragraph while viewing the page and share it for discussion. A correction to the saved review copy appears when colleagues reopen the existing active link. Record the actual sponsor authorization in the organization's maintained project record.