An ACS RPL project report for business analyst applicants lives or dies on one boundary: the line between business work and ICT work. You know your projects cold. What trips up experienced analysts is how fast an assessor demotes a narrative that reads as change management, stakeholder coordination, or process improvement rather than information and communications technology. Under ANZSCO 261111, the ICT Business Analyst occupation code, keeping a system or technology outcome at the centre of every paragraph is the job, even when the actual work felt like workshops, spreadsheets, and sign-off emails.
This guide assumes you already qualify and already know your projects. It focuses on the one framing move that decides the result.
Why Business Analyst Reports Fail the ICT Scrutiny Check
Most rejected reports do not fail on eligibility; they fail on framing. An ACS RPL project report for business analyst work can describe genuine ICT projects and still read as non-technical, because the language stays in the business register throughout.
The Business-versus-ICT Gap Assessors Flag
BA work straddles two domains by design. You sit between the business that wants something and the technology that delivers it. That middle position is exactly what makes the report hard: describe your work the way the business saw it, and it reads as facilitation; describe it the way the build team saw it, and it reads as ICT.
ACS assesses the nature of your actual duties, not your job title. The ANZSCO 261111 occupation description requires qualifying work to show requirements analysis, system improvement, and technical collaboration, not administrative or purely coordinating tasks. A report that lists meetings attended and consensus reached, with no system named, fails that test regardless of how senior the role was.
What ANZSCO 261111 Actually Asks Your Report to Prove
Two project reports are required: one from a project completed within the last two years, and one from within the last four. Each maps to the ACS Core Body of Knowledge (CBOK) through the topics you select on the RPL form. The form asks you to select topic areas from the CBOK and address subtopics under each; check the current ACS RPL form itself for the exact selection structure, because ACS revises it from time to time.
ACS does not publish an official word count per report. This guide targets roughly 1,000 to 1,500 words each, enough to show depth without padding. Write it yourself: ACS reserves the right to run similarity-checking software that cross-references your report against previously published material and other submitted applications.
Which BA Projects Pass the ANZSCO 261111 Depth Test
Project Types That Satisfy ICT Depth
The strongest BA projects tie your analysis directly to a named ICT system. Four types consistently clear the bar:
An ERP implementation or migration on a named platform such as SAP S/4HANA or Oracle Fusion, where you owned requirements and process design.
A CRM rollout on Salesforce or Microsoft Dynamics 365, where you specified objects, workflows, and integrations.
A business process automation build on a named platform, where you defined the logic the system executed.
A software requirements analysis that led to a system actually being built, where your specification is traceable to the delivered product.
Each keeps a technology at the centre. Your BPMN models, data dictionaries, and functional specifications then become evidence of ICT work rather than meeting minutes.
Work That Sounds Technical but Fails
Some projects feel ICT-adjacent and still fail the depth check. A stakeholder engagement programme with no named system reads as communications work. A change-management plan for a rollout you did not analyse or specify reads as organisational change, not systems analysis. A business case or feasibility paper that stops at cost and benefit, with no technical feasibility analysis, no data flows, and no solution requirements, reads as commercial writing.
The pattern is consistent: if the deliverable would still make sense with every technology reference deleted, ACS reads it as business work.
Writing the Project Background as an ICT Story
Keep the background short, roughly 150 to 200 words, and lead with the system, not the business pain. Name the platform, the environment it ran in, and the technical problem your analysis had to solve. The business problem earns one or two sentences of context, no more.
Business Framing versus ICT Framing, Side by Side
Here is the same two-sentence project description written both ways. The underlying work is identical; only the framing changes, and ACS reads them very differently.
Business framing: "I ran workshops with stakeholders to map our current-state processes and agreed a future-state design that everyone could support."
ICT framing: "I led requirements elicitation for the SAP S/4HANA finance migration, producing AS-IS and TO-BE BPMN process models in Enterprise Architect, documenting the order-to-cash data flows, and converting them into a functional specification the development team built against."
Same workshops, same week of work. The second version names a system, an artefact, a data flow, and a downstream technical outcome. That is the whole move, repeated in every paragraph.
Putting the System, Not the Process, at the Centre
A simple test keeps you honest: the grammatical subject of your sentences should often be the system, the data, or the specification, not "the business" or "the team." "The reconciliation module required a nightly interface" beats "The finance team wanted faster numbers" every time.
Documenting Your Role without Underselling ICT Work
Your role section, around 300 to 350 words, is where BA deliverables become ACS-recognisable technical tasks. Do not describe outputs in business language and hope the assessor translates. Translate them yourself.
Your BA deliverable | How ACS reads it under ANZSCO 261111 |
|---|---|
User stories, use cases, and acceptance criteria | Requirements engineering |
AS-IS and TO-BE process models (BPMN) | Systems analysis |
Entity-relationship diagrams, data dictionary | Data modelling |
Vendor shortlist with scored evaluation criteria | Software evaluation criteria |
UAT test scripts and defect register | Software testing and validation |
Write UAT as ICT work, not scheduling: name the test scripts you wrote, the system under test, and the defects you logged and retested. Write requirements as engineering: traceability from a business rule to a functional specification to a delivered feature. That trace is the evidence an assessor can follow.
Demonstrating ICT Knowledge Depth in the Narrative
Give your largest block, around 400 words, to knowledge demonstration tied to the CBOK topics you selected. This is where requirements and process work connect to technology outcomes. When you specified an integration between Dynamics 365 and a billing system, say what data moved, in which direction, through which interface, and why the design mattered. When you modelled data, name the entities and relationships, and explain the normalisation or reporting decision behind them.
Every 261111 assessor reads for a specific vocabulary: systems analysis, requirements engineering, data modelling, stakeholder analysis in an ICT context, and software evaluation criteria. When those concepts appear as real work rather than dropped terms, your BA contribution reads as ICT. Absent them, it reads as coordination.
Choosing and Writing Your Second Project Report
Your second report must cover different knowledge areas from your first. Two near-identical narratives with different project names waste the second submission and signal a narrow skill set.
Use the CBOK topics deliberately so the two reports cover different ground. A practical split for a business analyst:
Report 1: a delivery project where you specified and validated a system, aligned to the problem-solving and technology-building areas.
Report 2: a project where governance, vendor evaluation, or delivery oversight was central, aligned to the professional-knowledge and management areas.
Across both, you span problem solving, building, professional practice, and management, which is the breadth ACS wants to see. Confirm the exact topic names and numbers on the current ACS RPL form before you make your selection.
Within each report, hold to the blueprint: roughly 150 to 200 words of background, 300 to 350 on your role and ICT tasks, 400 on knowledge demonstration, and a tight 100-word close on the quantified ICT outcome. At least 60% of the narrative should cover your own technical tasks and decisions, not the surrounding project context.
Reviewing Your ACS RPL Project Report for Business Analyst
The review pass is where an ACS RPL project report for business analyst applicants earns its result. Run the ICT content density test paragraph by paragraph. For each one, ask a single question: if every reference to a system, technology, data flow, or ICT outcome were deleted, would a business narrative remain? A yes means that paragraph is not yet doing ICT work, and it needs a rewrite around the technology.
Then scan for the red flags assessors note in BA narratives:
Workshops described as elicitation sessions, with no artefact or system output named.
A project framed as "process improvement" with no technology platform identified.
UAT described as scheduling and sign-off, with no test scripts or defect register.
A conclusion that reports only a business outcome, such as cost saved, with no ICT result such as the system delivered or the integration stabilised.
One practical note before you commit the time: check the current validity period of your ACS outcome letter on acs.org.au so it still covers your visa timing, and if you hold a non-ICT degree or none at all, confirm your experience threshold first. The six-year versus eight-year rule sets out which applies to you.
FAQs
Can I Use a Project Where I Didn't Write Any Code or Configure Any Systems?
Yes. ANZSCO 261111 is an analysis occupation, not a development one, so ACS expects requirements, modelling, and evaluation work rather than code. What you must show is a named system at the centre of your work and technical artefacts you personally produced, such as functional specifications, data models, or software evaluation criteria.
What If I Led a Project as the BA but Developers Built the Actual Solution?
That is the normal shape of a BA project and fully acceptable. Write about the work that was yours: the requirements engineering, the systems analysis, the data modelling, and the UAT validation. Reference the build team where the handover matters, but keep your specification and your technical decisions in the foreground.
How Do I Write about Stakeholder Workshops So ACS Reads Them as ICT Work?
Name the system the workshop informed and the artefact it produced. "I ran a workshop" is business framing; "I ran requirements elicitation sessions that produced the TO-BE BPMN model and the functional specification for the Salesforce rollout" is ICT framing. The workshop is the method; the ICT artefact is the point.
Can I Use the Same Project I Described in My Employment Reference Letter?
Yes, and consistency between the two documents helps your case. The difference is depth: the reference letter confirms your role and duties, while the project report must go much further into the ICT tasks, technical decisions, and CBOK knowledge areas you personally covered.
How Is a Business Analyst RPL Project Report Different from a Software Developer's?
A developer's report centres on code, algorithms, and build and testing decisions. A business analyst's report centres on requirements engineering, systems analysis, data modelling, and software evaluation, with the system as the object of analysis rather than the object of construction. Same report structure, different knowledge areas demonstrated.
Once your two reports are drafted, read the step-by-step project writing guide to pressure-test your structure, or have a specialist review your draft with a BA-specific project writing service before you lodge.