SKIL90004 Chap.1 Project Foundations and Charters
Project Foundations and Charters
A scientific project needs a temporary purpose, an authorised boundary and inspectable evidence of success. This chapter connects the project life cycle with the charter, showing how background, rationale, goal, scope, deliverables, resources, risks and acceptance criteria form one control document. It also distinguishes project delivery from the wider benefit that may continue after the team closes.
The charter aligns why the work exists with what will be produced, what is excluded, which assumptions remain uncertain and who may accept the result. Its fields feed later planning: deliverables become decomposed work, constraints shape timing, resources shape feasibility and acceptance criteria return at close.
When new evidence changes the boundary, the charter supplies the reference for a visible decision rather than silent expansion.
What this chapter covers
- 01
Projects and operations
- 02
Life-cycle decisions
- 03
Charter purpose and authority
- 04
Scope inclusions and exclusions
- 05
Deliverables and acceptance
- 06
Assumptions, constraints and risks
Worked example · free
Charter a sensor feasibility pilot
- 1Define the decision the pilot must support.
- 1Separate feasibility work from later deployment.
- 1Name an approved protocol, dataset, analysis and decision brief as deliverables.
- 1Attach acceptance, authority and risk conditions.
Key terms
- Project charter
- A Project charter authorises temporary work and records its purpose, boundary, deliverables, authority and success evidence.
- Project life cycle
- A Project life cycle organises definition, planning, execution and close around the decisions required at each stage.
- Deliverable
- A Deliverable is an inspectable output that the project is committed to produce.
- Acceptance criteria
- Acceptance criteria state the evidence used to decide whether a deliverable is satisfactory.
- Constraint
- A Constraint limits how the project can be planned or executed.
Project Foundations and Charters FAQ
What belongs in a project charter?
Include the project purpose, background, goal, scope boundary, stakeholders, deliverables, resources, budget context, risks, mitigations and success evidence. The parts should describe the same project rather than acting as an unrelated checklist.
Why are exclusions important?
Exclusions make the boundary visible. When a worthwhile new request appears, the team can assess its effect on time, cost, quality, resources and risk instead of treating the additional work as an unnoticed commitment.
When is a scientific project complete?
Completion requires accepted deliverables, transfer of remaining responsibilities and a controlled close. The wider scientific or organisational benefit may continue after the temporary project team has disbanded.
Exam move
Redraw the life-cycle sequence and write a one-sentence decision for each stage. Practise converting broad aspirations into one purpose, three deliverables, explicit exclusions and acceptance evidence. Review every charter by asking whether a new team member could explain why the project exists, what it will produce, what it will not do and who accepts the result.
Begin a revision session with a blank charter for a small scientific feasibility project. Write the background as evidence of need, then make the goal describe the decision or change the project supports. Add scope inclusions and exclusions in parallel so the boundary is visible. Turn each deliverable into an inspectable noun and pair it with acceptance evidence.
List constraints separately from assumptions: a fixed access window is a constraint, while expected sample availability is an assumption until verified. Add risks that could invalidate the evidence, not generic headings. Next, compare every field for alignment. A goal about feasibility should not end with a deliverable promising full deployment. A success criterion should test the output named in the deliverable.
The decision owner must have authority to accept the result. Run a change drill by adding one attractive request after the charter is complete. Identify whether it fits the existing boundary. If it does not, describe the impact assessment and approval route rather than quietly expanding the plan.
Finish by mapping charter fields forward: deliverables become the work breakdown, constraints shape the schedule, resources shape feasibility, risks enter the register and acceptance criteria reappear at close. This trace makes the charter a control document instead of an introductory form. In a written answer, state the project purpose before listing activities.
Keep project success distinct from later product or organisational success, because valid evidence can support a decision not to deploy. When uncertainty remains, label it and name the review point. A carefully bounded conditional statement is stronger than a confident promise that the source evidence cannot support. For a final retrieval drill, cover the charter and reconstruct it from the project goal alone.
Compare your version with the original, noting missing authority, resources, assumptions or exclusions. Then reverse the exercise: read only the deliverables and infer the decision they should support. Misalignment becomes obvious when the inferred purpose differs from the written goal.
Close by writing one sentence that explains why the charter remains useful during execution and one sentence that explains how it supports formal close.
Working through Project Foundations and Charters in SKIL90004? Sia is AskSia’s AI Project Management tutor — ask any SKIL90004 Project Foundations and Charters question and get a clear, step-by-step explanation grounded in how SKIL90004 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
