ACSskillsassessment
ACS RPL

How to Choose Projects for ACS RPL: 4-Factor Scoring Rubric

You have eight projects on your CV and room to write up two. That gap is where most ACS RPL applications are decided. Knowing how to choose projects for ACS…

10 min read

You have eight projects on your CV and room to write up two. That gap is where most ACS RPL applications are decided. Knowing how to choose projects for ACS RPL settles your assessment long before you draft a single sentence, and picking the wrong two is a hard error, not a soft one, because the assessor grades what your projects demonstrate, not how well you narrate them.

This guide assumes you already know what the RPL pathway is and who needs it. What follows is a selection method: how to read your history the way an assessor will, score each candidate, and lock in a combination that holds up.

What ACS assessors look for in your project list

An RPL project report is evidence that you personally performed the tasks in your nominated ANZSCO occupation, at a professional level, recently enough to count. Three questions sit behind every project an assessor reviews, and they run in a fixed order.

ANZSCO alignment: the filter before everything else

Alignment comes first because it disqualifies in one line. Your nominated occupation, say Software Engineer 261313 or ICT Business Analyst 261111, carries a published task list in its ANZSCO definition. A project qualifies only when it demonstrates several of those specific tasks. A polished data-pipeline build does nothing for a 261111 Business Analyst claim if it shows no requirements elicitation, stakeholder analysis, or solution scoping.

Read your occupation's descriptors first and treat them as the rubric the assessor already holds. A project that fails this filter is out no matter how strong it looks on complexity or recency, so run every candidate past the task list before you weigh anything else.

The ICT-lead test: how deep was your role

A project you observed is worth less than a smaller one you drove. The rejection-audit guidance from acsskillsassessment.com frames this as SFIA-level competency: the assessor wants the decisions you made and the outcomes they produced, not a chronological task list.

For a Network Engineer 263114, an infrastructure rollout counts when you designed the topology and owned the cutover, not when you racked hardware to someone else's plan. Name the calls that were yours.

Outcome clarity and the official recency window

Two numbers settle the recency question, and they are not the ones on most writing-service blogs. ACS's own InfoHub guidance on RPL project reports requires one project completed within the last two years and one within the last four, measured back from your submission date rather than the calendar year. Third-party pages variously claim three and five years, and some say eight; treat those as unverified.

The eight-year figure conflates project recency with the separate work-experience threshold for applicants without a formal qualification, which is a different rule covered in the six-year versus eight-year guide. For selection purposes, the two-year and four-year windows bind.

Step 1: Inventory every project from your work history

Before you rank, list. Write down every candidate across every employer, with its dates, your role, and its deliverable. Most applicants under-count because they discount older or cross-employer work. Cast wide first, then cut.

What counts as a project versus routine support work

A project has a defined scope, a start, an end, and a deliverable someone signed off. Business-as-usual work recurs and never ends, however technical it is. This is the most common disqualification trigger, and it hides easily because both look like "work you did" on a resume.

Three contrasting pairs make the line concrete:

  • A system migration is a project. Resolving helpdesk tickets, even hundreds, is BAU.

  • A release sprint that ships a defined feature set is a project. Routine server patching is BAU.

  • A security gap analysis that produces a remediation roadmap (the kind a Cyber Security Advice and Assessment Specialist 262115 would own) is a project. Running weekly vulnerability scans is BAU.

The test is simple: can you name the day it ended and point to what changed because of it? If not, it is BAU. Technical difficulty does not convert ongoing work into an assessable project.

Surfacing candidates from older or multi-employer careers

A mixed career hides strong candidates in old roles. Dig through performance reviews, old status reports, and archived tickets to reconstruct scope and dates for projects you have half-forgotten. A four-year-old migration you led beats a current BAU role every time, provided you can still evidence your part.

Contractors and consultants should treat each engagement as a separate candidate rather than blurring a multi-year client relationship into one entry.

Step 2: How to choose projects for ACS RPL with a scoring rubric

Now rank. Score every candidate on four factors, rating each High, Medium, or Low. This rubric is the heart of how to choose projects for ACS RPL, because it turns a vague sense of which project felt important into a defensible shortlist.

The four-factor scoring checklist

1. ANZSCO task alignment: how many of your occupation's defined tasks the project demonstrates.

2. Technical complexity and ICT-lead role: the depth of the problem and how much of the decision-making was yours.

3. Measurable deliverable and documented outcome: whether you can evidence a concrete result.

4. Recency: whether it falls inside the two-year or four-year window.

A candidate that scores Low on alignment is out regardless of the other three. Complexity and outcome break ties. Recency decides which slot a project fills, not whether it qualifies at all.

Worked example: scoring three projects for Software Engineer 261313

Software Engineer 261313 reports should demonstrate designing and architecting software components, writing and testing high-quality code, applying a structured problem-solving method, and showing a measurable business outcome. Take this hypothetical history and substitute your own.

Candidate

ANZSCO alignment

Complexity and lead role

Measurable outcome

Recency

A. Microservices billing rebuild (2025)

High

High

High

Within 2 years

B. Custom inventory application (2022)

High

Medium

Medium

Within 4 years

C. Legacy ERP maintenance (ongoing)

Low

Low

Low

Current but BAU

Candidate C is current, which tempts applicants. But it scores Low on the first three factors, and recency cannot rescue it: maintenance is BAU. Candidates A and B are the finalists. Critically, they cover complementary task clusters. A carries the architecture and design tasks; B carries the coding and testing tasks. Together they cover the occupation's breadth instead of proving the same competency twice from different angles.

Disqualifying red flags to catch before you write

Catch these before you invest in a draft:

  • A BAU role dressed up as a project

  • A role described only in collective language ("the team delivered") with no isolated individual contribution

  • A project with no outcome you can evidence

  • Both candidates falling outside the four-year window

  • Two near-identical projects from the same employer

That last point costs you twice. The next section explains why.

Step 3: Build your final project combination

How many project reports ACS requires

ACS requires exactly two project reports per application. That single number drives everything upstream: you need at least two qualifying candidates, and ideally three, so you can drop the weakest rather than write it up because you have no alternative. Treat a shortlist of two as a warning sign, not a plan.

Balancing employer diversity and skill breadth

Your two reports should together span distinct task clusters from the ANZSCO definition, not restate one competency from two angles. Two near-identical projects from the same employer create a double problem. The assessment reads as narrow, and ACS cross-checks every report against its internal database of previously submitted applications, a layer no consumer plagiarism tool can reach. Two structurally similar narratives from the same employer are exactly the pattern that layer is built to flag. Spread your choices across employers and skill areas where you can; the plagiarism detection guide covers the mechanism in detail.

When a volunteer or academic project can substitute

A volunteer or academic project can fill a slot when it demonstrates the required ANZSCO tasks and documents your individual role clearly. The bar is the same as for paid work: a capstone where you architected and built a working system for a real client qualifies; a group assignment where your contribution cannot be separated does not. Substitute only when a work project genuinely cannot cover the task cluster, since assessors weight professional experience most heavily.

Project selection mistakes that cause RPL rejection

The pattern behind most rejections is upstream, not stylistic. Applicants pick BAU and call it a project, claim a code their projects do not evidence, or submit two reports that prove the same narrow skill. Getting how to choose projects for ACS RPL right at this stage is far cheaper than any rewrite after the fact. Run your shortlist through the rejection self-audit guide before you commit, and fix selection errors now, while they cost nothing but a rethink.

After you select your projects

With two finalists locked, confirm the surrounding evidence holds. ACS also requires at least two forms of professional currency evidence completed within the last two years, such as vendor certifications or structured professional development, so a shortlist of older projects still needs a recent currency counterweight. Confirm your nominated code and your experience meet the pathway requirements in the pathways overview before you write a word.

Once your shortlist is confirmed, read the companion guide on structuring your RPL project reports to turn these two projects into reports that pass.

FAQs

Can I use a project where I wasn't the technical lead?

Yes, if you can isolate your individual technical contribution and the decisions you personally made, even where your formal role was team member rather than lead. The assessor grades your part, not the team's. A team-member project with a clearly documented, substantial technical role beats a "lead" title with nothing concrete behind it. Vague collective language sinks these reports faster than a junior role does.

What if my strongest projects are older than eight years?

Age alone does not disqualify them, but at least one report must fall within two years and one within four, measured from your submission date. An older flagship project can supply supporting context, yet it cannot occupy either required slot on its own. If your best work is concentrated in older roles, prioritise finding a recent qualifying project first, then pair it with your strongest in-window candidate.

Is a freelance project valid if it ran alongside a full-time job?

Yes. A freelance or contract project can fill a report slot if it demonstrates the required tasks and documents your role, regardless of concurrent full-time employment. One caveat on the experience count: ACS counts work at a minimum of 20 hours per week toward your relevant-experience years, so a side contract below that threshold may serve as a valid project report while not adding to your experience total.

My title was IT Support but I did developer work. Which to pick?

Select on the tasks you performed, not your title, even when that title was IT Support while the work was development. The assessor maps evidence to the ANZSCO task list, so choose the projects where you did genuine development and can document it: code you wrote, components you designed, defects you resolved through deliberate engineering decisions. Your title on the org chart is irrelevant if the project evidence shows developer-level work.

Can one project appear in two RPL applications for different codes?

It is technically possible but risky. Reusing the same narrative across two separate submissions invites the internal-database self-plagiarism flag, because ACS cross-checks every application against all previously received ones. If a project genuinely supports two occupations, present distinct task evidence for each rather than recycling the text, and confirm the current nomination rules on the ACS site before you rely on one application covering both.