Project management, from charter to closure.
Eight modules on how projects actually get delivered — business cases, scope, schedules, budgets, risk, stakeholders and the waterfall-vs-Agile decision — taught in plain English with real depth. Finish with a 25-question exam and an instant certificate.
What you'll be able to do.
Written as demonstrable outcomes, the way the AQF frames them. On completing this course you will be able to:
- CLO1Distinguish projects from business-as-usual and explain the lifecycle, the triple constraint and the core roles around a project.
- CLO2Initiate a project properly — business case, charter, and SMART objectives with measurable success criteria.
- CLO3Define and control scope using requirements, a work breakdown structure and formal change control.
- CLO4Build and read schedules — dependencies, critical path, float and milestones — and estimate with three-point techniques.
- CLO5Manage budgets, risks and stakeholders with visible contingency, a live risk register and a communication plan.
- CLO6Select and justify a delivery approach (predictive, Agile or hybrid), report status honestly, and close projects with acceptance and lessons learned.
Who it's for: anyone who's been handed a project — team leads, coordinators, owners of "can you just organise this?" — and anyone aiming at a formal PM role. No prerequisites. Pairs well with Data Analytics Foundations (projects run on evidence, too).
Eight modules, kickoff to handover.
Each module states its learning outcomes, teaches the content, and sets an Apply it task. Everything in the exam is covered here.
Module 1What a project is — and what a PM does
- LO1.1Distinguish projects from business-as-usual and define the triple constraint.
- LO1.2Outline the project lifecycle and what each phase produces.
- LO1.3Describe the core roles — sponsor, project manager, team and stakeholders.
Core content
A project is temporary and delivers a unique outcome — it has a start, an end, and something that didn't exist before. That's what separates it from business-as-usual, the ongoing repeatable work that keeps an organisation running. Every project lives inside the triple constraint — scope, time and cost — with quality riding on all three: pull any corner (add scope, cut the deadline, shrink the budget) and the others must move. Pretending otherwise is how projects fail politely and then suddenly.
The lifecycle gives the work its shape: initiate (decide it's worth doing and authorise it) → plan (scope, schedule, budget, risks) → execute while monitoring against the plan → close (hand over, learn). Around it sit the roles: the sponsor owns the business outcome, funds the work and unblocks what the PM can't; the project manager delivers the outcome through other people — most of the job is communication and decisions, not doing the tasks; the team does the work; stakeholders are everyone materially affected, whether they're helpful or not.
Module 2Initiation — business case & charter
- LO2.1Explain what a business case contains and why projects start with "why".
- LO2.2Draft a project charter — objective, scope boundaries, success criteria, authority.
- LO2.3Write SMART objectives and measurable success criteria.
Core content
Projects start with why, not what. The business case makes the argument: the problem or opportunity, the options considered (including "do nothing"), the expected benefits, the costs and the major risks — is this worth doing at all? Once approved, the project charter authorises the project: it names the PM and their authority, states the objective, draws the scope boundaries, and defines the success criteria. One or two pages is plenty — its power is that everyone signed the same one.
Objectives earn their keep when they're SMART — specific, measurable, achievable, relevant, time-bound. "Cut average support response time from 8 hours to 2 hours by 30 November" can be tested; "make customers happier" cannot. Keep success criteria distinct from deliverables: the deliverable is the new website; success is "support calls down 30% within three months of launch". Benefits often land after closure — name who will measure them, or nobody will.
Module 3Scope & requirements
- LO3.1Gather and document requirements, separating must-have from nice-to-have.
- LO3.2Build a work breakdown structure (WBS).
- LO3.3Operate formal change control and recognise scope creep.
Core content
Requirements come from people — interviews, workshops, watching the actual work — and they arrive tangled with wishes. Prioritise explicitly (MoSCoW: must, should, could, won't) and write the out-of-scope list with as much care as the in-scope one; it's the cheapest insurance a project can buy. Then decompose: the work breakdown structure breaks deliverables into work packages small enough to estimate, schedule and hand to an owner — if you can't say who owns a package or how long it takes, break it down further.
Scope creep is the death of a thousand "small extras" — each reasonable, none assessed, jointly fatal. The cure isn't saying no; it's formal change control: a request is written down, its impact on scope, schedule, cost and risk is assessed, the right authority decides, and the baseline is updated. The process turns "yes" from a reflex into a decision.
Module 4Scheduling & estimating
- LO4.1Sequence tasks with dependencies and find the critical path.
- LO4.2Read and build Gantt charts, and use milestones.
- LO4.3Estimate with analogous and three-point techniques — honestly.
Core content
A schedule is tasks plus dependencies (mostly finish-to-start: paint after plaster). Chain them and one path through the network is longest — the critical path, which sets the minimum possible project duration. Tasks on it have zero float; delay any of them and the end date moves. Tasks off it have float — the amount they can slip without hurting the finish — which is where your flexibility lives. The Gantt chart draws all this as bars on a calendar; milestones are zero-duration checkpoints ("design approved") that make progress visible and arguable.
Estimating is where schedules are won or lost, because humans are optimists. Analogous estimating anchors on the last similar piece of work. Three-point estimating confronts the optimism directly: take optimistic, most-likely and pessimistic estimates and weight them — (O + 4M + P) ÷ 6. And keep buffers honest: padding hidden inside every task is invisible and gets spent; a visible contingency at project level is managed. Estimate in ranges, commit to dates carefully.
Module 5Budget, resources & procurement
- LO5.1Build a cost baseline with visible contingency.
- LO5.2Track spend against progress — earned-value thinking.
- LO5.3Compare fixed-price and time-and-materials contracting.
Core content
The budget is the WBS with prices on it: cost each work package, sum them, then add a contingency reserve — visible, sized to the risks, and managed — rather than hiding fat in every line. Resources need the same realism: a person booked at 200% across two projects is a schedule written in fiction; level the load or change the dates. The plan you can defend is the one with the buffers on display.
Tracking spend alone tells you nothing — spending fast isn't progress. Earned-value thinking compares money spent to work actually completed: 60% of budget gone with 40% of the work done means the project is over budget for what it has delivered, and you know it now, mid-flight, not at the end. For bought-in work, contract shape allocates risk: fixed price shifts cost risk to the supplier (who prices it in, and charges hard for changes); time & materials stays flexible but leaves the cost risk with you. Stable scope favours fixed; evolving scope favours T&M with tight oversight.
Module 6Risk & stakeholders
- LO6.1Maintain a risk register with likelihood × impact ratings and owners.
- LO6.2Choose risk responses — avoid, mitigate, transfer, accept.
- LO6.3Map stakeholders by power and interest, and plan communications.
Core content
A risk is an uncertain event that would matter if it happened — distinct from an issue, which already has. The working tool is the risk register: each risk described, rated for likelihood × impact, given an owner and a response — and reviewed on a cadence, because a register nobody reads is decoration. The four responses: avoid (change the plan so the risk can't occur), mitigate (reduce likelihood or impact), transfer (insurance, or a contract that moves it — buying cover for storm damage is a transfer), and accept (small ones, consciously, in writing).
Stakeholders get the same discipline. Map them by power and interest: high-power high-interest people are managed closely — engaged early and often; high-power low-interest kept satisfied; low-power high-interest kept informed; the rest monitored. Then write the communication plan: who gets what information, how often, in what form — the sponsor's monthly one-pager and the team's daily standup are answers to the same question. Surprises are the project manager's natural enemy; silence is how they breed.
Module 7Delivery approaches — predictive, Agile & hybrid
- LO7.1Explain predictive (waterfall) delivery and when it fits.
- LO7.2Explain Agile delivery — Scrum and Kanban — and when it fits.
- LO7.3Choose and justify an approach, including hybrid, for a given project.
Core content
Predictive (waterfall) delivery plans the whole project up front and executes in sequence — requirements, design, build, test, deliver. It fits when requirements are stable and well understood (construction, compliance work, anything physical or regulated) and change is genuinely expensive late. Agile flips the bet: deliver in small usable increments, learn from each, adapt. Scrum runs fixed-length sprints from a prioritised backlog, with a review and retrospective every cycle; Kanban runs continuous flow with WIP limits — stop starting, finish what's in progress.
Two corrections to folklore: Agile is not "no planning" — it plans continuously, in smaller increments, steered by feedback; and standups alone don't make a team Agile (ritual without empiricism is just a meeting). Choose by uncertainty: how clear are the requirements, how available are the stakeholders, how regulated is the work? In practice hybrid is the norm — a predictive shell (fixed funding gates, fixed end date) around iterative build. The skill the AQF calls "judgement" is exactly this: matching the approach to the context and saying why.
Module 8Execution, monitoring & closing well
- LO8.1Run honest status reporting (RAG) and clear accountability (RACI).
- LO8.2Monitor against baselines and manage issues as they land.
- LO8.3Close properly — acceptance, handover and lessons learned.
Core content
Execution is where the plan meets people. RACI keeps accountability sharp — for each piece of work, who is Responsible (does it), Accountable (owns it — exactly one person), Consulted and Informed. Status reporting runs on RAG (red/amber/green) and on honesty: going amber early, with a recovery plan attached, is competence — not failure. The "watermelon report" (green outside, red inside) is how projects die with perfect paperwork. Monitor against the baselines you set — scope, schedule, cost — and when something has already happened it's an issue: log it, own it, work it.
Closing is a phase, not an email. Take acceptance against the charter's success criteria (the ones everyone signed), hand the outcome to business-as-usual with the documentation to run it, release the team properly, and hold the lessons-learned session while memories are fresh — what to keep, what to change, recorded where the next project will find it. The classic failure causes — unclear scope, optimistic estimates, silent stakeholders, an absent sponsor — are all preventable, and every one of them is set up (or defused) in the phases you've just learned.
How this course maps to AQF Level 4.
The Australian Qualifications Framework defines each level by three criteria — knowledge, skills, and application of knowledge and skills. This course's outcomes and exam are designed against the Level 4 criteria (the level of the Certificate IV), quoted below from the framework.
| AQF Level 4 criterion | The framework says… | How this course addresses it |
|---|---|---|
| Knowledge | "Graduates at this level will have broad factual, technical and some theoretical knowledge of a specific area or a broad field of work and learning." | Modules 1, 4 and 7 build broad factual, technical and some theoretical knowledge of the discipline — lifecycle and constraint theory, critical-path scheduling, estimating method, and the predictive/Agile delivery frameworks (CLO1, CLO4, CLO6). |
| Skills | "A broad range of cognitive, technical and communication skills to select and apply a range of methods, tools, materials and information to: complete routine and non-routine activities; provide and transmit solutions to a variety of predictable and sometimes unpredictable problems." | Requirements capture and WBS construction (M3), scheduling and three-point estimating (M4), risk and stakeholder method selection (M6), and the communicate-it Apply it tasks (charters, status reports, comms plans) train selecting, applying and transmitting solutions (CLO2, CLO3, CLO5). |
| Application of knowledge and skills | "Graduates at this level will apply knowledge and skills to demonstrate autonomy, judgement and limited responsibility in known or changing contexts and within established parameters." | Applied tasks demand autonomous work with judgement inside set parameters — drafting a charter with boundaries (M2), sizing visible contingency against named risks (M5), choosing risk responses (M6), and justifying a delivery approach per context (M7) (CLO2, CLO5, CLO6). |
Criteria quoted from the AQF levels published at aqf.edu.au. The AQF also specifies volume of learning for qualification types (typically 0.5–2 years for a Certificate IV); at ~10 hours plus practice, this course aligns its outcome design to Level 4 descriptors but does not approach a qualification's volume of learning — one more reason it is not, and does not claim to be, an AQF qualification.
Plain-English status: this is a non-accredited course. Its certificate is a completion certificate issued by Course Contact, designed with reference to AQF Level 4 descriptors. It is not an AQF qualification (only ASQA/TEQSA-accredited providers can issue those), confers no licence, and Course Contact is not a registered training organisation. Want an accredited Certificate IV in Project Management Practice or a Diploma of Project Management? We'll match you with providers, free →
From kickoff to closure. Prove it.
25 questions across all eight modules — 80% to pass, options shuffle every attempt, certificate issued instantly.