Skip to content

Lab 01 — Writing a Project Charter

At a glance

Learning objectives

By the end of this lab you should be able to:

  1. Turn a vague idea into a bounded project definition.
  2. Write purpose, scope boundaries, and success criteria that another person could act on.
  3. Identify assumptions and constraints explicitly.
  4. State what is out of scope, and why that matters.

Scenario

You are the newly assigned project manager for the Campus Event Portal — a small web application that lets student societies publish events, lets students discover them, and lets staff moderate listings.

The idea was approved verbally. Nobody has written anything down. Different people have different expectations:

  • The student societies want to publish events in minutes, with images.
  • The university IT office wants it to use existing single sign-on and to pass a security review before launch.
  • The student affairs director, who is paying for it, wants it live before orientation week.
  • A student developer volunteers to build it part-time.

Your job in this lab is to write the charter that turns this into a defined project.

Your role

You are the project manager, appointed by the student affairs director. You have not been given a written brief, a budget breakdown, or a defined scope — only the conversations described above. The charter you write will be the first document in the project's record, and the director will sign it.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

Work with the facts in the scenario exactly as given. Where you need information that nobody has provided, write it down as an assumption rather than inventing a fact — the assumptions log is part of the assessment.

Useful context you can rely on:

  • Orientation week is a fixed date in the university calendar and cannot move.
  • The student developer is available roughly one day per week.
  • The university IT office performs security reviews on its own schedule, and its queue length has not been stated to you.
  • The student affairs director has budget authority for this project and can approve scope changes.

Tasks

Task 1 — Establish purpose and success criteria

Write two or three sentences stating why this project exists and what success means. Success must be observable — "societies can publish an event without staff help" is observable; "users are happy" is not.

Task 2 — Draw the scope boundary

List what is in scope and — importantly — what is out of scope for the first release. Choose at least three exclusions that a reasonable person might otherwise assume were included (for example: mobile apps, payments, event analytics, integrations with the university calendar).

Task 3 — Identify constraints and assumptions

Record constraints (fixed dates, required integrations, available hours) separately from assumptions (things you believe to be true but have not confirmed). Flag any assumption that, if false, would invalidate the plan.

Task 4 — Define authority and governance

State who sponsors the project, who approves the charter and scope changes, and what the project manager is authorised to decide alone.

Task 5 — Capture initial risks and stakeholders at a high level

List three to five candidate risks and the main stakeholder groups. You will develop these fully in later labs; here, just show you can spot them.

Deliverable

A completed charter using the Project Charter template, one to two pages. Submit it in Markdown, PDF, or as a document — format is not assessed.

Aim to complete the charter before reading any model answer, and mark your own work first.

Hints and guidance

  • Write the exclusions before the inclusions. It is much easier to see whether the project is finishable once you have said what it will not do.
  • Success criteria must be observable. Test each one by asking who would observe it, and what they would see. If no observation could show the criterion unmet, it is not a criterion.
  • Separate constraints from assumptions. A constraint is a limit you must work within; an assumption is a belief that could be false. A fixed date is a constraint; "the IT office will review within two weeks" is an assumption.
  • Authority is not status. State what the project manager may decide alone, and what must go to the sponsor. A charter that does not say this will produce an argument later.
  • The volunteer developer is the project's capacity constraint. If your plan does not reflect roughly one day per week, it is not a plan.

Self-check criteria

Mark your own charter. Award up to 2 points per row.

Criterion 0 1 2
Purpose Missing or vague Stated but generic Clear, specific, tied to stakeholder need
Success criteria Absent or unobservable Partly observable Observable and testable
In scope Missing Broad list Specific, prioritised
Out of scope Missing One or two items Several plausible exclusions, with reason
Constraints vs. assumptions Conflated Both listed, some confusion Clearly separated, risky assumptions flagged
Governance and authority Missing Sponsor only Sponsor, approver, and PM authority defined
Risks and stakeholders Missing Listed but shallow Insightful, relevant to the scenario
Clarity Hard to follow Readable Concise; another person could act on it

Interpretation: 12+ is solid; 14+ is strong; below 10, revisit Module 02 before moving on.

Full model answers and marked examples are in the Beginner labs answer key. Attempt the lab independently first — the key is a reference, not a template.

Reflection

  1. Which was harder — deciding what was in scope, or what was out? Why?
  2. Which single assumption, if wrong, would most damage this project?
  3. Your sponsor wants the portal before orientation week. Did you accept that date uncritically, or record it as a constraint to test? Defend your choice.

Extension challenge

Rewrite the charter for a different sponsor. Assume the student affairs director is replaced by the university's chief information officer, who cares about security, integration with existing systems, and not adding another application to the estate.

Then answer:

  1. Which parts of your charter change, and which parts stay the same? Explain why.
  2. Which of your success criteria would survive the change of sponsor, and which were designed around one person's preferences?
  3. What does the exercise reveal about the difference between a charter that documents a project and one that merely records a conversation?

Keep this artefact

You will reuse and extend this charter in the Capstone Project.