Simplifying imports service — Alpha assessment
The aim of this service is to simplify international trade and the importation of goods across Australia's border. To achieve this the service team focussed in Alpha on developing the Digital Permit Service. This service will reduce the need for industry to present paper permits to clear prohibited and restricted imported goods by digitally capturing Australian Government permit data.
- Department / Agency
- Department of Immigration and Border Protection
- Date of Assessment
- 24 February 2016
- Assessment type
- Digital Transformation Agency-led
- Assessment stage
- Result of Assessment
- Lead Assessor
- Matthew Landauer
- Service Manager
- Steve Moore
Assessment report summary
Outcome of service assessment - Pass
The Department of Immigration and Border Protection imports service team has shown sufficient progress and evidence of meeting criteria 1, 2 and 3 of the Digital Service Standard as required in an Alpha assessment. The team are on track for the other criteria.
The assessment panel noted that:
- The team ably demonstrated that they had a solid understanding of the needs of end users and users within the department. They identified a number of significant pain points that users, both from industry and within the department, experience.
- The team showed how the alpha would simplify the importation process for brokers and how the alpha simplified the process of checking permits for Pre-Clearance Intervention (PCI) Officers.
- The team demonstrated that they were working together in an agile way. They showed how they planned their sprints, and how what they learned from the usability testing fed directly into the subsequent iteration.
Areas of good performance against the Standard
User needs (Criteria 1)
The team demonstrated a deep understanding of user needs. They showed strong evidence of much contextual user research carried out with many users of different types in different locations both inside and outside of government. They also interviewed different businesses and brokers. Overall they did research with 51 users outside government.
Multidisciplinary team (Criteria 2)
The team demonstrated that they were working in a multidisciplinary team. The team demonstrated that they were pairing on most activities to ensure knowledge transfer between team members in the short term. They demonstrated how “good user research is a team sport”.
Responsive design (Criteria 9)
The prototype demonstrated showed good use of responsive design techniques.
Accessible (Criteria 10)
The team demonstrated that they have done work with accessibility consultants and included a wide range of end users as part of user research.
The assessment panel makes the following recommendations.
Multidisciplinary team (Criteria 2)
The team has a significant number of interim contractors, especially around user research, service design and development. The team will need to put in significant effort to ensure that the knowledge and capabilities will be transferred into the agency over the mid to long-term.
Agile and user centred (Criteria 3)
Alternative concepts had been deselected early in the process on grounds of security concerns. We feel these concerns are broad and might be overstated. Ideally we would like to have seen the team investigate this area in greater detail.
During Beta the team should continue to thoroughly test the new service in the context of the whole process for the PCI officer and continue to look for improvements that can be made to the service which will improve the end-to-end process for the PCI officer.
Data, tools and systems (Criteria 4)
For Beta, the team have chosen technologies which closely align with the capabilities of the agency’s IT function. They should ensure that these technologies do not constrain an agile and multidisciplinary approach during the development of the Beta service.
Measures (Criteria 6)
The team should meet with the DTO Performance Dashboard team to ensure that the Beta service is able to publish performance data as soon as is practicable.
Open source (Criteria 8)
The alpha code is not currently open source. The team does not see any barriers to either the alpha or beta code becoming open source.
For beta the team should aim to code in the open from the start.
Assessment against the Digital Service Standard