You have gathered the reference letters, confirmed your ANZSCO code, and set aside the fee. Then you open the form and stall, because writing an ACS RPL project report is where most applications actually come apart. Assessors treat the project reports as the heart of the RPL case. Generic, team-voiced, or loosely mapped writing is the most common reason a strong career gets referred back for more information.
Two facts are worth establishing before you type a word. ACS requires two project reports for the RPL pathway: one describing a project from within the last two years and one from within the last four. ACS publishes no word-count thresholds; it asks only that each report offer enough detail to show the depth and breadth of the IT knowledge you have accumulated. You get two slots, so treat each one as a distinct piece of evidence and give it the length its evidence needs.
What a well-structured ACS RPL project report actually achieves
An assessor reads your report to answer one question: did this person personally apply the competencies of their nominated ANZSCO occupation? Structure is what lets them answer it fast. A report ordered by STAR (Situation, Task, Action, Result) puts your individual technical decisions where the reader expects to find them, so your competency is legible on the first pass instead of reconstructed from a wall of narrative.
Why structure determines how far the assessor reads
Assessors work a queue. A report that hides the applicant behind project background holds their patience for only so long. If the first third is company history and the technology stack lands as a bullet inventory, the reader has to hunt for the one thing that matters: your hands on the work. A tightly mapped 400-word report that reaches your individual Action quickly outperforms a 900-word narrative that never commits to a competency.
The two reports ACS expects and what each must prove
Each ACS RPL project report must stand on its own as evidence rather than lean on the other. Because you have two slots, the reports should span different competency clusters from your ANZSCO unit group. Two reports demonstrating the same handful of skills waste half your evidence. The goal is coverage across your unit group, not a highlight reel of your largest engagements.
Before you write: confirm your ANZSCO code and gather project evidence
Map your ANZSCO unit group competencies before choosing projects
Open your nominated occupation's ANZSCO unit group description and read the listed tasks and skills as a checklist of competency clusters, not as background reading. For 261313 Software Engineer, those clusters separate roughly into designing and building software, testing and debugging, maintaining and modifying live systems, and applying engineering discipline across the lifecycle. Group them, because your two reports should land in different clusters. A cross-check against the ACS skills assessment pathways also confirms RPL is the right route before you invest hours in writing.
What project details to have on hand before you open the form
Pull the concrete specifics for each candidate project first: your exact role and reporting line, the technologies you personally worked in, the decisions you made rather than inherited, the timeline, and any measurable or observable outcome. Confirm each project's dates match the dates on your reference letters exactly, because a mismatch there is an easy referral trigger. If your role was non-project, ACS lets you substitute the reports with a structured account of your work experience and the challenges you handled, per its RPL guidance, and the same competency-mapping discipline still applies.
Step 1, Choose two projects that cover different competency clusters
Project selection decides more of your outcome than any sentence you write. Choose badly, and even flawless prose demonstrates the same narrow slice twice.
How to match each project to a distinct ANZSCO competency cluster
Take the grouped clusters from your mapping step and tag every candidate project with the one or two clusters it most strongly evidences. You want two projects whose primary clusters barely overlap. A backend engineer might pair a greenfield service build (design and construction) with a production incident and remediation effort (maintenance, testing, and reliability). Each proves a different competency face of the same ANZSCO code.
A decision matrix for picking your strongest two
When several projects qualify, score them instead of guessing. Rate each candidate 1 to 5 on four axes, then weight the axes by how much ACS assessment actually rewards them:
Criterion | Weight | What a 5 looks like |
|---|---|---|
ANZSCO competency-cluster alignment | ×3 | Directly evidences a named cluster in your unit group |
Degree of individual contribution | ×3 | You made and owned the technical decisions |
Recency | ×2 | Within ACS's currency window (last two to four years) |
Project complexity | ×1 | Non-trivial technical or architectural difficulty |
Multiply each score by its weight and sum. Worked example: a project scoring 5 on alignment (15), 4 on contribution (12), 5 on recency (10), and 3 on complexity (3) totals 40, compared with a larger but older team project scoring 4, 2, 2, and 5, which comes to 12 + 6 + 4 + 5 = 27. The smaller, recent, self-owned project wins. Complexity carries the lowest weight on purpose: a modest system you clearly drove beats an ambitious one where your fingerprints are faint.
Why recency and your individual role outweigh project scale
The weighting reflects what ACS actually assesses. ACS asks for recent work: one report from within the last two years and a second from within the last four, so professional currency is built into the requirement rather than optional. ACS assesses you, not your former employer's ambitions, so a project where you owned the design decisions carries more evidentiary value than a flagship program in which you were one contributor among twenty. Scale impresses readers. Ownership and currency convince assessors.
Step 2, Write the Situation and Task sections
What the Situation section must establish in two to three sentences
Keep Situation short. In two or three sentences, establish the business problem the project solved, the technical context, and enough scale for the assessor to gauge difficulty. Skip the company history. Situation exists only to make your later Action legible, so give the reader the problem and the constraints, then move on.
How to frame your Task without overstating your seniority or scope
Your Task is your assigned responsibility on this project, stated precisely. If you led a subsystem, say so; if you were one of several engineers, name the slice you owned rather than implying you ran the whole program. Overstating scope is a credibility risk, because the Action section then has to deliver on a claim it cannot support, and that gap is visible to a reader who assesses these for a living. Claim exactly what you did, and no more.
Step 3, Write the Action section (where assessors spend the most time)
Action is where the assessment is won or lost. Let it run to roughly 50 to 60 percent of each ACS RPL project report's word count, because it is the section that shows competency in motion. The other three sections set it up; this one carries the proof.
What 'Action' means when you were one of several engineers
On a team project, Action means your steps and your decisions, isolated from the collective 'we'. Write in the first person and stay there. Instead of 'we migrated the service', write what you did inside that migration: the component you owned, the approach you chose, the trade-off you weighed, the problem you solved when that approach hit a wall. Team context stays as backdrop; your individual technical reasoning is the subject of every Action sentence.
How to name tools and systems without making a list
Name your tools inside the action, never as an inventory. 'Skills used: Go, Redis, gRPC, Docker' tells an assessor nothing about how you used any of them. 'I rewrote the token-validation middleware in Go and moved rate limiting to a Redis-backed counter to hold the endpoint under load' shows the same tools doing work. The verb carries the competency; the tool is only its object. Weave every technology into a sentence where you are the one making it do something. The project writing guide works through more examples of this technique.
Annotated Action section for a software engineer
Here is a model Action passage for a software engineer (ANZSCO 261313) who was one of four backend engineers on an internal API migration. It is illustrative, not a template to copy verbatim:
> I owned the authentication and rate-limiting layer of our migration from the legacy monolith's REST endpoints to a set of gRPC services. I profiled the existing endpoints under production traffic, found that token validation was the dominant latency cost, and rewrote the validation middleware in Go against a shared identity library. When the first cutover attempt caused intermittent 401 errors under load, I traced it to a race in the token-cache refresh, moved the cache to a Redis-backed store with a single-writer refresh, and added contract tests so the new gRPC handlers rejected malformed tokens exactly as the old REST layer had.
Every sentence has an 'I' doing something technical, and the four-engineer team is context, not the actor. The tools appear as objects of real decisions, not a shopping list. The passage narrates a problem hit and solved, which evidences engineering judgment rather than mere task completion, and it maps cleanly to the design, construction, and testing clusters of the 261313 unit group.
Step 4, Write the Result and anchor it to your ANZSCO code
How specific your outcomes need to be and when exact figures help
State the outcome as concretely as you honestly can. A measurable figure helps when you actually have it: latency dropped, error rates fell, a release cycle shortened. When you have no defensible number, describe the observable result rather than inventing precision or reaching for vague impact language. 'The migrated endpoints handled the same peak traffic without the timeout errors the legacy layer produced' is specific and checkable without a fabricated percentage. Honest and observable beats precise and unprovable.
Connecting the result back to a named ANZSCO competency
Most reports stop at the outcome and skip the closing move. After stating the result, name the ANZSCO competency it demonstrates, explicitly. One sentence closes the loop: the outcome shows you applied a specific cluster from your unit group. A Result with no competency anchor leaves the assessor to infer the mapping, and an inference you could have made for them is one that might not land. Every Result should end by pointing back at the code.
Step 5, Self-check both reports before submitting
Five structural questions to ask before you lodge
Read each ACS RPL project report against five questions before lodging:
1. Does each report demonstrate a different competency cluster from my ANZSCO unit group?
2. Is the Action section the longest part, written entirely in the first person?
3. Does every technology appear inside an action I performed, not as a list?
4. Does each Result name the specific competency it proves?
5. Does one report fall within the last two years and the other within the last four, and do both sets of dates match my reference letters?
A 'no' to any of these is a structural fix, not a wording tweak.
What triggers an ACS referral back specifically on project reports
Referrals on project reports cluster around a few structural failures rather than grammar. The report reads as a team narrative with no isolable individual contribution. Both reports map the same competency, so half the evidence is redundant. A Result asserts an outcome with no competency anchor. Or the writing trips originality checks: ACS prohibits outsourcing reports to writing agencies and reserves the right to run plagiarism detection, so anything that reads as generic or AI-generated invites scrutiny. The plagiarism-detection guidance is worth a pass on its own.
Structural mistakes that stall otherwise complete applications
Writing a team narrative instead of an individual contribution
The most common failure is the collective voice. A report full of 'we designed' and 'the team delivered' proves the team was competent, which ACS is not assessing. Rewrite every collective verb into the specific thing you did inside it. This one fix resolves more referrals than any other change.
Padding the Result section with vague impact language
'Delivered great results' and 'improved performance significantly' are noise to an assessor. They carry no competency signal and read as filler covering an absence of real outcome. Replace them with the observable change. If a project genuinely has no outcome you can point to, that is a reason to choose a different project.
Submitting two reports that demonstrate the same competency
Two reports on the same cluster waste half your evidence. It usually happens when applicants pick their two biggest projects, which often exercise the same skills, instead of their two most cluster-diverse ones. Return to the matrix: the goal is coverage across your unit group, not a ranking of your largest engagements.
Structure is the difference between two ACS RPL project reports that read as evidence and two that read as career storytelling. Map your clusters, pick two diverse projects, put your individual Action at the center of each, and anchor every Result to your ANZSCO code. Before you lodge, run your completed reports through the ACS RPL rejection reasons self-audit guide to catch the structural issues assessors flag most often.
FAQs
Can I use the same project in more than one ACS RPL project report?
No. Each of your two reports must cover a different project. Reusing one project across both reports collapses your evidence into a single competency demonstration and defeats the purpose of the two-report structure, which exists to show range across your ANZSCO unit group.
How do I write the STAR Action section if I worked in a team?
Write the Action entirely in the first person and describe only the components and decisions you personally owned. Keep the team as context ('one of four engineers'), then isolate your slice: what you built, what you chose, and what you fixed. ACS assesses your individual competency, so a team-voiced Action that never separates your contribution is a common referral trigger.
Should I pick the biggest project I have worked on, or the one that best matches my ANZSCO code?
Pick the one that best matches your ANZSCO code and where you personally owned the technical decisions. Size impresses, but ACS scores your individual competency against your occupation. A smaller project you clearly drove and that maps to a named cluster outperforms a large one where your role was diffuse.
Can I include a project from more than 10 years ago in my ACS RPL project report?
ACS wants recent work: it asks for one report from within the last two years and one from within the last four. A project older than that can appear as supporting context inside a report, but it will not satisfy the currency requirement on its own, and leaning on it as a primary submission risks a referral on recency grounds. Keep both of your reports inside the two-year and four-year windows.
How specific do results and outcomes need to be, do I need exact figures?
Exact figures help when you genuinely have them, but they are not mandatory. State a measurable outcome where you can defend it, and an observable one otherwise. What ACS needs is a concrete, verifiable result tied to a competency, not an invented percentage. Vague phrases like 'improved performance significantly' add no competency signal and read as padding.