• Agencies must notify the Digital Transformation Agency’s (DTA) Investment Advice, Contestability and Assurance Branch by emailing investment@dta.gov.au as soon as they plan to bring forward a digital and ICT enabled proposal. 

  • For whole-of-government initiatives and platforms, the agency leading the digital and ICT build must consult with the DTA.

    The DTA will assess whether the proposal qualifies for the IIAP based on the criteria outlined on this page. The agency may be asked to provide further information at this point, including a Risk Potential Assessment Tool (RPAT), to support the assessment of the proposal.

    For proposals subject to the IIAP, agencies are requested to follow the timeframes specified by the DTA to submit draft and final business cases (including supporting materials) for review. This generally requires agencies to provide draft business cases at least 7 weeks prior to the Cabinet consideration date, and final business cases at least 1 week before circulating the Cabinet Submission for coordination comments. The DTA will discuss timeframes with agencies when advising them if the proposal is subject to the IIAP.

    Does the IIAP apply to my proposal

    If you have a new policy proposal or an internally funded proposal for Cabinet consideration, the IIAP will apply if your agencies’ proposal meets all 3 conditions:

    • it is digital and ICT-enabled (the policy or service delivery outcomes are highly dependent on the underpinning digital and ICT system)
    • the total whole-of-life cost is estimated to be $30 million or more, including total whole-of-life digital and ICT costs of $10 million or more (whole-of-life costs must include operational costs, capital costs, and maintenance costs)
    • it is assessed by the DTA as high risk through consideration of a Risk Potential Assessment Tool (RPAT) assessment (this risk may relate to factors such as significant change, cost, technical or business complexity, workforce capacity and schedule).

  • Proposals subject to the IIAP follow a staged approval process (previously known as the ‘two pass’ Cabinet approval process). At each stage of approval, agencies must develop a business case to provide Cabinet and its relevant committees with sufficient information about the proposal to make an informed investment decision.

    The DTA can work with you to determine the minimum business case requirements relevant to your proposal. The process is designed to be flexible to cater for different types and complexities of ICT enabled proposals that require Cabinet approval. For example, second pass may result in a one-off approval process or, for more complex proposals, subsequent stages may be required.

    In developing your business cases, you must consider how your proposal aligns with whole-of-government ICT standards and policies, including Cyber Security.

    You should also contact your Chief Finance Officer (CFO) unit to ensure that you are aware of and comply with current Department of Finance Estimates Memorandums, covering the Budget Process Operational Rules and the ICT Investment Approval process.

  • Cabinet may request that your proposal undergo the process, even if it does not meet all these criteria.

  • Templates to download

    The following resources will assist you in developing your business case:
    1st pass business case template (Word, 225 Kb)
    2nd pass business case template (Word, 102Kb)
    Department of Finance Business Case Guide (PDF, 959Kb)

  • No results found.

    More digital news and events

  • Public evaluation briefing

    Thank you to those who attended our public briefing on Friday 25 October 2024. Catch up on the briefing below or download a copy of the slide deck (PDF, 120KB).

    In the coming weeks, the DTA will publish answers to questions from attendees on this page. To receive updates, consider subscribing to the DTA's AI in government newsletter.

  • General inclusion

    Do’s 

    • Use common patterns for design components.
    • Use a linear, logical layout.
    • Write in plain English.
    • Display clear hints and error messages, with appropriate symbols, below text boxes.
    • Provide content in a variety of mediums to support different preferences.
    • Build in modern coding languages e.g. HTML 5 or later.
    • Ensure code scripts are readable by, and work with, support tools.
    • Test using keyboards for navigation and different browsers.
    • Reduce screen complexity by providing white space and content that is not cluttered.
    • Start with accessibility in mind and test regularly throughout the design process.

    Don’ts 

    • Limit or provide inconsistent touch tap areas.
    • Provide hint text in boxes that disappear when the box is clicked.
    • Use complex technical terms.
    • Quickly ‘time out’.
    • Force mouse or screen use.
    • Require excessive validation processes for online applications.
    • Make dynamic content that requires a lot of mouse movement.
    • Use decorative or cursive font styles.
    • Allow video or audio content to play automatically.
    Off
  • People who are blind or vision impaired

    Do’s

    • Use common patterns for design components.
    • Use a linear, logical layout.
    • Write in plain English.
    • Show clear hints and error messages below text boxes using simple words and icons.
    • Provide content in a variety of mediums to support different preferences.
    • Build in modern coding languages e.g. HTML 5 or later.
    • Ensure code scripts are readable by, and work with, support tools.
    • Test using keyboards for navigation and different browsers.
    • Reduce on screen complexity by providing white space and content that is not cluttered.
    • Include accessibility in the design as early as possible and test application of standards throughout.

    Don’ts

    • Limit or provide inconsistent touch tap areas.
    • Provide hint text in boxes that disappear when the box is clicked.
    • Use complex technical terms.
    • Quickly ‘time out’.
    • Force mouse or screen use.
    • Require excessive validation processes for online applications.
    • Make dynamic content that requires a lot of mouse movement.
    • Use decorative or cursive font styles.
    • Allow video or audio content to play automatically.
    Off
  • People who are cultural and linguistically diverse (CALD)

    Do’s 

    • Use clear headings and simple language. Provide definitions if needed.
    • Consider cultural context, like warnings for photos of deceased persons.
    • Use images and videos to simplify and explain information.
    • Provide guides and documents in a variety of languages.
    • Use certified translators for critical information.
    • Provide translations and custom help text on the same page.
    • Consider how service changes may impact users who rely on consistency.
    • Provide alternative contact methods, including interpreter services.
    • Provide user feedback when an action is completed correctly.
    • Provide translated error messages to support troubleshooting.

    Don’ts 

    • Use complex layouts, structures or menus.
    • Separate related information across different webpages.
    • Provide video or audio information, unless also accompanied by text.
    • Use complicated words, figures of speech or long blocks of text.
    • Rely on automatic translations. Check translated terms for accuracy.
    Off
  • People who are Deaf or hard of hearing

    Do’s

    • Ensure all videos have transcripts, captions and provide text descriptions for images.
    • Provide content in a variety of mediums to support different preferences.
    • Offer users options for how they interact with your service.
    • Make it easy to access support services.

    Don’ts 

    • Only show information in an image or video.
    • Spread content all over a page.
    • Rely on text size and placement for structure.
    • Force mouse or screen use.
    • Write uninformative links and headings – for example, Click here
    Off
  • People impacted by family and domestic violence

    Do’s 

    • Provide clear information on how safety concerns are reported and escalated.
    • Offer a simple ‘quick exit’ function.
    • Make it easy to restrict access from personal or shared accounts.
    • Offer choice about how and when to receive information.
    • Offer translation software that enables non-English speakers to access support.
    • Use empathy in the tone of communications.

    Don’ts

    • Make users re-explain sensitive circumstances across government services.
    • Send communications during hours where user action is unlikely to occur.
    • Make users complete processes in a single session.
    • Complicate validation steps for applications.
    Off
  • People with low digital literacy

    Do’s 

    • Allow users to start and stop processes across different communications channels.
    • Accompany key takeaways with clear calls to action.
    • Provide clear step by step instructions, to support key information and action points.
    • Use progress indicators to show task advancement.
    • Provide mobile responsive designs.
    • Make it easy to reset passwords and build on tasks.
    • Support older browsers and devices.
    • Group related content together to improve discoverability.
    • Use repeatable icons and visual cues to build user familiarity and confidence.
    • Provide equivalent alternatives to auditory and visual content.

    Don’ts 

    • Assume users have prior knowledge of digital tools.
    • Play videos and audio content automatically.
    • Use technical terminology.
    • Limit the time available to complete tasks.
    • Show error messages too quickly.
    Off
  • Neurodiverse people

    Do’s 

    • Respect user settings to remove motion.
    • Let users manage auto-refresh.
    • Consider animations carefully.
    • Use images such as icons and symbols with text.
    • Provide plenty of white space around information.
    • Carefully consider information display and order.
    • Use progressive reveal to reduce cognitive load.
    • Use clear affordance to help navigation.
    • Keep content short, clear and simple.
    • Let users change the contrast between background and text.

    Don’ts 

    • Rely on device/user movement.
    • Use strobing or rapid flashing effects.
    • Use all uppercase letters.
    • Use text that is both left and right justified on the same page.
    Off
  • People with physical disability

    Do’s

    • Design with ‘mobile first’ design patterns.
    • Test in both vertical and horizontal views.
    • Remove navigation that requires complex hand movement.
    • Ensure the touch tap area is the widest possible area and consistent across the site.

    Don’ts 

    • Create interactions that require precision.
    • Put multiple interactions together.
    • Have short time out windows or error messages that display too soon.
    • Tire users with lots of typing and scrolling.
    Off

Connect with the digital community

Share, build or learn digital experience and skills with training and events, and collaborate with peers across government.

Join the Digital Profession