ACS RPL Project Reports: How to Build Evidence Around Your Real ICT Work

What ACS currently asks RPL applicants to prepare

ACS describes RPL as an assessment pathway for experienced IT, data science and cyber security professionals who do not hold relevant tertiary qualifications. The current RPL document set includes identity evidence, work-experience evidence, two RPL Project Reports and professional currency evidence.

ACS states that one RPL Project Report should cover a project completed within the last two years and the other should cover a project from within the last four years. Applicants in non-project roles can instead describe work experience and challenges faced during that period.

Professional currency is a separate requirement. ACS currently asks for at least two forms of evidence demonstrating skills and currency in the nominated ANZSCO occupation, with the evidence related to the chosen skills and occupation and completed within the last two years.

The project-selection mistake that creates problems later

A prestigious project is not automatically a strong RPL project. A huge transformation programme can become a weak report if your own ICT contribution is buried under statements such as “the team developed”, “we implemented” or “the project delivered”.

Choose projects where you can reconstruct your own work. You should be able to explain what information you reviewed, what problem you identified, what requirement or technical dependency you clarified, what options you considered, what decision or recommendation you made, and what changed as a result.

For an ICT Business Analyst, useful evidence may include process analysis, requirements engineering, business rules, data mapping, interface requirements, API behaviour, traceability, UAT design or production issue analysis. For an ICT Project Manager, the evidence may be different, but it still needs to demonstrate professional ICT-level work closely related to the nominated occupation.

Build a project evidence map before writing

Before drafting, create a simple evidence map for each project. This reduces contradictions and prevents the report from becoming a generic career summary.

• Project identity: exact project name, employer, client if applicable, location and dates.
• Your position: title, team context and the period in which you personally participated.
• Business or operational problem: what was not working and why the project existed.
• ICT environment: applications, platforms, integrations, data flows, APIs, cloud services, databases or delivery tools genuinely relevant to your work.
• Your analysis: workshops, process models, requirements, system analysis, data mapping, dependency analysis, defect analysis or other methods you personally used.
• Your decisions and recommendations: the choices you made or influenced and the evidence behind them.
• Challenges: a real ambiguity, integration failure, data issue, delivery dependency or other problem you personally helped resolve.
• Outcome: measurable results where genuinely available, or a concrete operational or delivery outcome where a metric was not formally recorded.
• Supporting evidence: employment records and professional currency material that can substantiate the broader claims in your application.

First-person evidence is more than using the word “I”

Changing “we analysed the integration” to “I analysed the integration” does not make a claim stronger if the report still does not explain the analysis. Good first-person evidence describes the applicant’s thought process and action.

Compare “I supported API integration” with a more informative factual structure: “I reviewed the request and response fields required by the consuming application, identified that refund status was represented differently in two systems, documented the mapping and clarified the failure scenarios with the service team.” The second version gives an assessor something concrete to understand.

Do not invent technical depth to sound more senior. If you did not design or code an API, say what you actually did: clarified interface requirements, reviewed payload fields, coordinated dependencies, analysed error scenarios, defined acceptance criteria or supported end-to-end validation.

Professional currency should not be an afterthought

An applicant can have long ICT experience and still leave professional currency evidence until the end. That is risky preparation. Review the current ACS professional currency categories and identify recent evidence that genuinely relates to the nominated occupation.

The key questions are relevance and recency. A recent course with no relationship to your nominated occupation may be less useful than evidence showing current practice in the actual skills you claim. Keep dates, completion records and a short explanation of relevance ready.

Common RPL weaknesses to check before submission

• Project dates do not align with the employment history.
• The report describes the programme but not the applicant’s personal ICT work.
• Responsibilities read like a copied occupation description rather than real project evidence.
• The same generic contribution is repeated across both projects.
• Technologies are listed without explaining how the applicant interacted with them.
• Challenges are vague and do not show analysis, decisions or problem solving.
• Outcomes are exaggerated or presented without a factual basis.
• Recent professional currency evidence is missing or unrelated to the nominated occupation.
• The applicant keeps adding polished language but has not resolved basic evidence gaps.

A better way to prepare

Treat RPL preparation as an evidence exercise before treating it as a writing exercise. Select the occupation carefully, map your work history, choose recent projects with strong personal contribution, identify missing facts, and only then structure the report.

Skill2Australia is designed around this preparation sequence: identify project candidates, surface evidence risks, ask focused questions about missing information and help organise the applicant’s own facts. The applicant must review every statement and ensure it reflects real experience and supportable evidence.