Implementing a New Infringements Management System

Tabled: 5 May 2021

Snapshot

Did the Department of Justice and Community Safety (DJCS) roll out its new infringements system in an effective and cost-efficient way? 

Why this audit is important

On 31 December 2017, DJCS introduced a new information technology (IT) system, called the Victorian Infringements Enforcement Warrant (VIEW) system, to manage fines and incorporate new social justice initiatives.

DJCS had failed in a prior attempt to implement a new fines IT system and Victorian public sector agencies have had persistent issues with implementing new IT projects. It is therefore useful to assess DJCS's performance in implementing VIEW so it and other government agencies can apply learnings to future projects.

Who we examined

  • DJCS
  • Department of Treasury and Finance (DTF).

We did not examine the performance of the vendor who DJCS contracted to supply VIEW.

What we examined

  • project governance and oversight
  • DJCS's procurement process
  • DJCS’s project implementation and management of risks
  • DJCS's management of its chosen vendor.

What we concluded

DJCS's significant failures in planning the VIEW project meant that its implementation did not meet the expected time, cost, quality and functionality targets.

These failures were mainly due to DJCS's misguided and poorly implemented risk mitigation strategy to procure a commercial off-the-shelf (COTS) system. This is because no COTS system existed, or could reasonably be expected to exist, that could meet DJCS’s complex requirements.

 

 

The Victorian public service must rethink its approach to sourcing, managing and governing its complex IT projects to avoid these issues recurring.

It must also re-examine its approach to providing robust advice to the government, especially when the government may not be receptive to the advice.

What we recommended

We made a total of seven recommendations to the Department of Premier and Cabinet, Department of Treasury and Finance (DTF) and Victorian Public Sector Commission. Our recommendations relate to leadership training for public servants, building information technology project delivery capability, risk management and project governance. All recommendations we made were accepted. 

Video presentation

Video transcript

Key facts

Key facts

What we found and recommend

We consulted with the audited agencies and considered their views when reaching our conclusions. The agencies’ full responses are in Appendix A.

Developing VIEW 

In 2015, the Department of Justice and Community Safety (DJCS) began reforming Victoria's fines system after the Victorian Ombudsman and the Sentencing Advisory Council found weaknesses with it and DJCS’s ability to enforce fines. The Victorian Infringements Enforcement Warrant (VIEW) project was not DJCS’s first attempt to replace its legacy fines information technology (IT) system. Its previous replacement project was terminated after it overran by six years and cost $59.9 million, which was over twice the planned cost of $24.9 million.

DJCS started procuring a vendor for VIEW in January 2016. It gave its chosen vendor 15 months from signing the contract to implement VIEW by the planned go live date of 31 December 2017.

By July 2017, DJCS and the vendor realised they could not deliver the required functionality within the set timelines and agreed to change the contract. After July 2017, the vendor continued to not meet all timelines and delivery requirements. DJCS decided to launch VIEW on the agreed go-live date with as much functionality as it could deliver.

DJCS expected VIEW to deliver 90 per cent of its required functionality at the go-live date. However, following its launch, it became apparent that the vendor had delivered substantially less functionality than DJCS expected, which DJCS later estimated to be 5 per cent on go live. This had significant, negative implications for Fines Victoria’s ability to process and enforce infringements and meet its legislative requirements.

A minimum viable product has just enough core functionality to effectively deploy in order to learn as much as possible about the business viability of the product. Deploying it is a strategy used to seek feedback and validate the product development to date.

In 2019, DJCS engaged a consultant to explore VIEW's delivery issues and develop a remediation plan. DJCS and the vendor have continued to improve VIEW's functionality and deliver it as a minimum viable product to support the fines system. DJCS reports that it has added a range of functionality to VIEW that has improved its capacity to progress court fines and action warrants. We did not review DJCS's remediation efforts or substantiate VIEW's current level of functionality as this was outside the audit scope. To date, VIEW is still incomplete.

In October 2019, DJCS decided that it will not deliver VIEW in the form it originally intended and is aiming for a more modern technology solution to better meet the long-term needs of the fines system. 

Failure of governance

DJCS’s overall governance of the VIEW project was ineffective. As a high value high risk (HVHR) project, it posed significant risk and materiality to the state. However, DJCS's governance arrangements, oversight and reporting were not commensurate with the project's importance and challenging nature.

Under the Department of Treasury and Finance's (DTF) HVHR Project Assurance Framework, government infrastructure and IT projects that are identified as high value and/or high risk are subject to more rigorous scrutiny and approval processes than other projects. The framework requires HVHR projects to undergo assurance checks and processes that are designed to increase the likelihood of meeting timelines and budgets and delivering intended benefits.

DJCS failed to fully inform the Attorney-General about the project's substantial risks and likely consequences, did not harness the required expertise and did not adequately respond to findings from DTF's gateway reviews, which are intended to identify and address risks to significant government projects.

Lack of robust advice

In the project's early stages, DJCS made some effort to convey the likely risk that VIEW would not meet its go-live deadline to the Attorney General. DJCS also sought an extension to the project. However, it did not:

  • clearly prioritise the issue in its briefs to the Attorney-General, which instead largely focused on the changes required to the draft fines reform legislation to meet social justice policy aims
  • provide any detailed explanation of why it needed additional time, such as a realistic timeline based on past government IT procurement projects, or the necessary steps to procure and implement a major IT project while setting up the new Fines Victoria business unit
  • clearly explain the link between the IT solution and delivering the fines reform, and the likely consequences that failing to deliver the IT solution on time would have on implementing the reform.

Our interviews with many DJCS staff who were involved in the VIEW project revealed that when the Attorney-General granted a project extension that was less than what DJCS requested, they accepted the deadline as immovable. These staff also told us that they lacked the power to direct the project and experienced internal pushback when they continued to highlight risks to its delivery. For example, DJCS never submitted a brief that it drafted for the Attorney-General, which conveyed the risks in substantial detail. DJCS advised us that the draft brief informed verbal conversations with the Attorney General’s office. However, because there is no record of these conversations, we cannot determine the level of detail that was discussed.

As VIEW's launch date approached, DJCS's reporting to the Attorney General was overly optimistic. This was partly due to the inaccurate reporting it received from the vendor, the IT advisor that DJCS hired from an external advisory firm and its project team. DJCS also failed to accurately report known risks. It recommended to the Attorney-General that the launch go ahead, despite not having fully tested the system, adequately trained its staff or having contingency arrangements in place if the launch failed.

If public servants fail to provide full and robust advice to government, it points to cultural weaknesses and inconsistencies with the public sector code of conduct. The code requires public servants to provide honest, sound, frank, impartial and timely advice to government. There can be a range of pressures that may lead public servants to compromise the code of conduct's requirements. However, upholding the code is core to their role and the effective functioning of the government. As such, the challenges that senior public servants face in consistently meeting this expectation warrant open discussion within the public service and with government.

Recommendations about robust advice

We recommend that:   Response
Victorian Public Sector Commission in consultation with Department of Premier and Cabinet  1. strengthen leadership training and development to focus on, and facilitate conversations about, public servants':
  • role in providing advice to the government (see Section 3.1)
  • expectations for full and frank advice (see Section 3.1)
Accepted
2. develop guidance for public servants on how to meaningfully engage with ministerial offices to appropriately convey risks and mitigation options for major projects and strategic activities (see Section 3.1). Accepted

Capability for major IT projects

The Victorian public service and most other Australian jurisdictions have a history of problematic and failed IT projects, as does the private sector.

With the VIEW project, DJCS's failure to identify, procure and implement an effective IT solution immediately followed its previous failed attempt.

DJCS did not engage enough people with skills commensurate to the nature and complexity of the VIEW project. This core issue was exacerbated by DJCS's ineffective oversight and review processes.

Lack of adequate IT project and technical expertise

Developing and delivering a major and complex IT project is equivalent to a major capital works project. It requires a high degree of technical knowledge and experience as well as detailed planning and project management.

A gateway review is an independent external review of a project or program at key decision points in its life cycle. DTF's infrastructure and assurance team oversees these reviews and provides advice on a project's progress and likelihood of successful delivery.

DJCS either did not recognise or did not fully acknowledge its gaps in technical expertise, which was an issue that the project's gateway reviews highlighted. DJCS also retained many staff from its previous failed IT solution for fines management to work on VIEW, despite acknowledging that the failure of the previous project was related to skill deficiencies.

DJCS's lack of expertise in relevant software solutions and leading complex IT projects led it to over-rely on a contracted IT advisor from an external advisory firm. This IT advisor’s background and experience was not appropriate for the scale and complexity of the project though. DJCS tasked the advisor with multiple and conflicting roles across vendor procurement, project delivery and reviewing and assuring the project's progress. This significantly compromised the independence and quality of advice provided to the project steering committee.

DJCS's lack of appropriate knowledge and experience meant that its staff were unable to properly consider IT options that could realistically deliver on its policy intent, evaluate the claims of potential vendors and critically interrogate performance reports from the IT advisor and vendor.

There are many legacy IT systems that need to be replaced across the Victorian public sector. The demand for new IT solutions to meet citizens' changing needs and expectations and drive efficient government service delivery will also continue to grow. This requires strong technical and project delivery capabilities that are specific to IT within the public service. It also requires senior executives to recognise and acknowledge any limitations they have in these areas and address them through appropriate resourcing.

Recommendation about IT project capability

We recommend that:   Response
Department of Premier and Cabinet 3. establishes an information technology projects centre of excellence to create a centralised, dedicated team of information technology project and technical experts dedicated to building capability across government and support agencies to plan and implement ICT-related projects (see Chapter 4 and Chapter 5). Accepted

Ineffective oversight

DJCS's steering committee for the VIEW project was poorly constituted and governed, particularly in its early days. In December 2015, DTF's gateway review of VIEW criticised DJCS for having a steering committee that was too reliant on consultants and lacked independent, expert members. DJCS was slow to address these findings, doing so only after key procurement decisions had been made.

The steering committee failed to identify and manage key project risks and allowed deadlines to slip without analysing and addressing the root cause of problems. A number of factors contributed to this, including that the:

  • project lacked a clear owner, with the director of Fines Victoria not hired until November 2017, despite initial intentions to have this role filled by December 2016
  • steering committee reported directly to the Attorney-General and therefore did not benefit from DJCS's executive board or secretary's oversight
  • steering committee membership lacked continuity, with multiple membership changes throughout the project
  • project was led by three different deputy secretaries across its life.

These factors diminished accountability for decision-making and project delivery.

Gateway review process

DJCS participated in the gateway review process as required for a HVHR project. While the reviewers highlighted risks to the VIEW project, DJCS did not fully use the gateway reviews to improve its chances of success.

DJCS did not derive the maximum possible benefit from the gateway reviews because:

  • the senior responsible officer (SRO) for the project was more junior than DTF's guidance recommends. DTF defines the SRO as ‘the person in the client organisation who is ultimately accountable to Government for the successful delivery of the project.’ However, VIEW's SRO was more junior than the deputy secretary who was responsible for the project within DJCS. This limited visibility over issues raised by the gateway reviews and their resolution
  • the SRO did not ensure that the gateway reports received sufficient attention from senior staff. While DTF's guidance recommends that SROs share reports upwards, reviewers do not directly provide their reports to project steering committees, except for risks that they rate ‘red’, which they communicate to the Treasurer. This is intended to promote open disclosure by the SRO to reviewers. However, this practice allows SROs to conceal lesser issues raised in reviews from stakeholders and others accountable for the project
  •  the SRO did not initiate the reviews in a timely way, which meant that they could not serve their purpose as early warnings
  • DJCS did not address some risks identified in the gateway reviews. This allowed the identified matters and associated risks to continue or recur.

The gateway reviewers also did not give a high enough rating to some key risks. They did not make recommendations for all identified risks either, which limited awareness of, reporting, and action against these risks.

Recommendations about governance

We recommend that:   Response
Department of Treasury and Finance 4. takes an active role in following up if agencies are addressing red rated risks identified in gateway reviews and seeks assurance from agencies that they are briefing the relevant ministers on these issues (see Section 3.3) Accepted
5. updates its gateway review guidance to require senior responsible officers to send full reports to project steering committees (or equivalent) (see Section 3.3) Accepted
6. monitors the progress of high value high risk projects to intervene if requests for gateway reviews are not initiated by agencies in a timely way (see Section 3.3) Accepted
7. develops and documents a transparent rating matrix for risks identified through gateway reviews (see Section 3.3). Accepted

An uninformed buyer

DJCS’s business case refers to debtor centricity as 'allowing a holistic understanding of the debtor and their situation to support the development of effective strategies for agreeing to payment arrangements'.

The fines reform legislation aimed to address social justice issues related to fines and introduce the concept of debtor centricity to bring together the management of all fines for an individual. With over 120 agencies issuing fines and individual fines processes having bespoke legislative, regulatory and business process requirements, there was significant complexity for DJCS in operationalising these reforms.

DJCS sought to procure and implement an IT solution to help achieve this. However, VIEW ultimately has not met the requirements of fines reform with a number of causal factors driving this outcome.

Bias based on past experience

DJCS’s earlier attempt to implement a new IT solution for fines management failed. That project had sought to build a customised IT solution from the ground up. A lessons learnt report identified that DJCS lacked IT expertise and was an uninformed buyer. However, our interviews with DJCS staff involved in the procurement and implementation of VIEW found that the main ‘lesson’ staff took from the prior failure was to avoid attempting another customised IT build. This led to a fixed preference for a commercial off-the-shelf (COTS) IT solution with minimal customisation. DJCS staff felt that this would avoid the complexity of the past attempt and fit the timeline for fines reform implementation.

COTS products are packaged and ready-made IT software or hardware products that can be purchased and implemented as is or slightly adapted to satisfy the purchaser's needs. They are the opposite of commissioning a custom made solution that is tailored to a specific purchaser. For example, Microsoft Office is a COTS product.

This was unrealistic because COTS solutions are designed and intended for delivering mass, simple transactions. Fines management in Victoria involves a myriad of complex and bespoke processes. Using a COTS solution could have met only some elements of the fines management system. Alternately, fines processes would have required significant simplification and streamlining to fit the COTS solution, which DJCS did not contemplate.

As DJCS limited its procurement strategy to only consider COTS options that could be delivered in the prescribed time frame, it biased the advice it gave to government on available options.

Inadequate understanding of needs

Before approaching the market in 2015, DJCS did not have a sound understanding of:

  • the proposed fines reform legislation
  • the business needs of the new Fines Victoria business unit
  • the systems and processes for fines management across the multiple fine types and agencies involved.

At the time, DJCS had not yet established the Fines Victoria business unit, nor appointed its director, and work was still continuing to develop the detail of the fines legislation. DJCS had also completed limited consultation with stakeholder agencies regarding their needs. As a result, DJCS lacked a fully invested project owner to properly specify its system requirements to potential vendors.

DJCS went to market with underdeveloped specifications that were partially based on outdated and misleading requirements from the previous failed IT project, which had different delivery objectives and therefore did not accurately reflect the updated requirements.

DJCS subsequently agreed to settle a compensation claim lodged by the vendor, where the vendor alleged that DJCS had:

  • increased the scope of work outside the original contract
  • made multiple changes to the system's specifications
  • provided inadequate specifications
  • delayed clarifying complex requirements.

Poor vendor evaluation

Settling for a solution that was not fit for purpose

DJCS did not set up its vendor evaluation criteria to support it to select a solution that would meet its needs. DJCS’s criteria overemphasised lesser requirements and did not appropriately regard fundamental technical elements. Based on DJCS’s difficulties with the vendor for its past failed project, DJCS allocated almost 37 per cent of the evaluation criteria to support in-project capability and customer service. Vital technical requirements, such as interfaces, reporting and generating fines correspondence, each accounted for less than 5 per cent.

Functionality fit is when software fully meets the requirements of the user without any modifications.

Furthermore, DJCS’s tender evaluation system was confusing and did not reveal the extent to which customisation would be required. DJCS's final tender assessment revealed that the top two vendor systems had functional fit scores of only 63.3 per cent and 63.2 per cent respectively. This indicated that DJCS would require significant customisation to meet all of its needs and adapt to its business processes. However, DJCS did not question this gap or consider an alternative way to deliver the policy reform's requirements.

There is also no evidence that DJCS tested the preferred vendor's ability to customise its offerings to close the functionality gap. Further, once DJCS selected a product with a low technical fit, it did not adjust its timelines to factor in the extensive customisation necessary. In October 2017, the steering committee acknowledged the extent of the gap between DJCS's expectations and the chosen solution. It noted the vendor had re-engineered its entire core product to add the required functionality. To date, VIEW has still not achieved full functionality.

Lack of due diligence over vendors

Three members of the project team, as well as DJCS’s contracted IT advisor, undertook an international site visit to the United States of America and the United Kingdom to test the products of potential vendors, as none had a substantial Australian base. Despite DJCS's intent to review and assess the applicability of the potential software solutions to the Victorian fines reform's requirements, the site visit team did not have the necessary IT expertise to undertake that task. Documentation of the site visits gives no indication that the team sought or were provided demonstrations of all the relevant software components needed for VIEW. The team also only visited one of four prior customers of the successful vendor.

DJCS also did not undertake simple inquiries that it could have made from Melbourne. Doing so would have revealed that the successful vendor’s product had never been tested at the scale and complexity required to manage fines in Victoria. It had only been applied in local councils in London for traffic and parking fines and in local libraries for transactions in the hundreds of thousands each year. This was clearly not comparable to the roughly six million often complex fines transactions Victoria undertakes yearly. Such due diligence should have alerted DJCS of the likely incompatibility of the solution and negated the need for site visits.

Procuring an outdated solution

SaaS is a software delivery model in which a provider licenses a cloud-based software application to a user. The application is accessed via the internet, meaning the user does not install and maintain the software locally. 

DJCS also failed to understand the potential options to meet its project needs. In focusing on pursuing a COTS system, it limited itself to what is considered outdated technology. DJCS did not deeply contemplate technology that would support a ‘software as a service' (SaaS) option, which reflects a more contemporary approach. This further demonstrates DJCS’s lack of IT technical expertise. Even within the IT field, it is challenging for individuals to maintain expertise due to the fast pace of progress, so public servants need to be alert to the potential that their ‘expert’ may lack the most up-to-date knowledge.

Failure to manage risks

Project management issues

Throughout the project, DJCS failed to identify and/or address key risks to its project management, including:

  • failing to determine and apply an accepted IT project methodology
  • not planning for or managing the interdependencies between its multiple work streams, including developing and implementing the new legislation, setting up the Fines Victoria business unit, engaging a new business services provider and the VIEW IT project
  • intentionally choosing to not do contingency planning due to its belief that ‘failure was not an option’. This view missed the intent of contingency planning, which is not undertaken as an alternate delivery strategy, but as a fail-safe should unexpected obstacles arise
  • poorly managing its contract with the vendor. Contrary to their contract, DJCS released payments to the vendor before system components had passed testing. DJCS paid 83 per cent of the build amount by the launch date. This left DJCS with little leverage over the vendor, particularly when it emerged that the system had much lower functionality than expected
  • inadequately testing VIEW. As milestones slipped, DJCS responded by compressing the time for system testing and undertaking concurrent user acceptance testing. The inadequate testing resulted in DJCS not knowing what the system could or could not do before it launched. DJCS was then surprised by VIEW's lack of functionality on launch.

Loss of focus on intended benefits

DJCS delayed creating and approving a comprehensive benefits management plan until May 2019, which was 43 months after the government approved the business case. This was also 32 months after a gateway review recommendation to implement one, and 17 months after VIEW was launched.

Without clarity on which benefits were most important and a plan on how to achieve them, DJCS lost focus on its aims. In August 2018, DTF’s project assurance review (PAR), which complements its gateway reviews, confirmed that DJCS had drifted from its objectives. The review stated that there was a ‘considerable disconnect between the outcomes that are being achieved and the benefits that were intended to be achieved at the business level’.

One key intended outcome of fines reform was debtor centricity. However, DJCS did not define and give prominence to debtor centricity in the early stages of the project or ensure that the vendor delivered on this. In September 2018, DJCS conceded there was a mismatch in its expectations and the vendor’s understanding of debtor centricity. This was after the system had gone live.

Contractor conflict of interests

DJCS relied on several external consultants to supplement its in-house capability. However, as previously discussed, it relied heavily on one IT advisor who became closely involved in multiple key aspects of the project. This eroded the objectivity of the IT advisor and compromised the quality of their advice.

That DJCS did not manage the conflict of interest that this situation created was a governance failure. DTF's gateway reviews also challenged the extent of the IT advisor's involvement, saying it risked 'diluting its ability to provide truly independent advice'. Despite a gateway recommendation to source new independent advice, DJCS persisted in using the same advisor.

In February 2018, following the gateway recommendation to source a new independent advisor, DJCS requested and received approval to deviate from state purchase contract rules. This allowed DJCS to not go to tender but obtain a sole quotation to appoint the same advisor to an active role on the project. DJCS cited the advisor's close and long-running involvement with the VIEW project and their existing relationship with the system vendor to support the appointment. However, DJCS did not address the conflicts of interest raised by the same arguments.

Our audit found that the IT advisor's reporting was overly optimistic, not evidence-based and misleading.

Failure to manage increasing customisation

DJCS undermined the potential time and cost benefits of choosing a COTS option by expanding functionality through a poorly controlled customisation process. 

DJCS's chosen solution was poorly matched to its needs, which made customisation necessary to add the required functionality. However, DJCS did not manage the customisation process well. DJCS did not seek to accommodate the functionality of the base product by adjusting its own processes and timelines. Recognising that it needed to customise the system to try to implement VIEW as intended, DJCS added to the system's requirements and made ongoing change requests. This was a more costly undertaking than simply implementing a COTS and VIEW was no longer an ‘off-the-shelf’ product.

Senior VIEW project team members advised us that customisation to the vendor’s base product could be as high as 70 per cent, which demonstrates that ultimately, DJCS did not purchase a COTS product.

In May 2017, DJCS closed off the customisation risk in its risk register and said there was limited opportunity to customise. By that time, the vendor was already delaying software delivery milestones at least in part due to the level of customisation work occurring.

On 13 October 2017, the steering committee acknowledged that the vendor’s base product had been completely re-engineered. This was only two months before the go live date. However, DJCS did not reopen the matter on the risk register.

DJCS’s failure to manage the increasing risk from customisation resulted in:

  • reactive and incremental resourcing because the vendor did not have the staff with the required expertise readily available
  • the need for far more software testing than planned, which was affected by the compression of time available for testing due to the project missing its milestones 
  • significant pressure in the final stages because development and testing happened concurrently
  • a sizeable number of software defects
  • additional costs.

Note about recommendations

Despite the extent of our findings, this report does not directly make recommendations to DJCS regarding the management of this project. All of our findings relate to matters where there are already clear requirements outlined through various government and departmental policy and procedure documents and guidelines. As such, the broad recommendation is for agencies, particularly DJCS in its ongoing work to develop appropriate IT solutions for fines management, to diligently understand and comply with these expectations when undertaking major projects and engage the technical competence needed for such work.

Back to top

1. Audit context

While Victoria Police and local councils issue most of the fines in Victoria, over 120 authorities have the power to do so. Historically, individual agencies often administered their own fines.

In 2015, DJCS began to reform the Victorian fines system. It created Fines Victoria as a centralised contact point for fines. The reform program included a project to procure a new IT system, called VIEW, to support the reform and replace the existing outdated system.

1.1 The need for fines reform

Criticisms of fines management

Governments and enforcement agencies use infringement penalties (or fines) to deal with minor law breaking. A person issued with a penalty notice has the choice of paying a fixed penalty rather than attending a court hearing. This streamlines the fines system for both the state and those issued with a fine.

However, the management of fines in Victoria has been long criticised. In its 2013 report, the Victorian Ombudsman found an outdated technology system was impairing DJCS's ability to enforce fines. A 2014 Sentencing Advisory Council report recommended:

  • creating a centralised administrative body to manage and enforce infringements and court fines
  • Centrepay is a free and voluntary service to pay bills and expenses as regular deductions from a person's Centrelink payments.

    facilitating a wide variety of payment methods, including Centrepay, direct debit, and online payments
  • providing a combined statement of debt to a person rather than sending separate correspondences for each debt
  • developing a compliance model and case-managing different fine-recipient groups to ensure appropriate sanctions for enforcement are directed to particular groups of people.

Fines reform

DJCS subsequently developed a new policy and proposed a new model for fines processing and enforcement.

The intent of the fines reform program was to increase the efficiency and effectiveness of processing and revenue collection and to improve the experience of debtors, particularly vulnerable Victorians. The fines reform aimed to:

  • centralise managing and enforcing infringements and court fines with Fines Victoria
  • shorten collection and enforcement time frames
  • provide improved social justice initiatives to support vulnerable and disadvantaged people to deal with their fines
  • enhance and streamline review processes to ensure a fair and transparent infringement system and reduce the burden on the court system.

The idea of debtor centricity was core to the fines reform. The goal was to create a one stop shop for debtors to manage all their fine debt fairly and effectively regardless of the issuers. To achieve this, DJCS required a new IT system capable of aligning and administering fines records against individuals rather than infringement events. This means that when an individual has multiple fine debts, the system can recognise them as attached to the same person and group the fines together.

Concurrent system-wide change

DJCS began its fines reform program in 2015. The program changed major elements of the Victorian fines system and its operation. DJCS set up its program in a way that meant all the changes took place at the same time in January 2018. This ‘big bang’ approach, which required a full transition to the new system at a legislatively fixed deadline, added significant risk and complexity to what was already a large transformation process.

Figure 1A shows the components of the fines reform program.

FIGURE 1A: Components of the fines reform program

FIGURE 1A: Components of the fines reform program

Source: VAGO.

These transformation projects all had to be delivered in a way that ensured the business continuity of Fines and Enforcement Services (FES)—the DJCS business unit responsible for fines, because fines processing continued throughout the reform.

DJCS originally intended to mitigate this risk by enacting the program components progressively in a specific order. It planned to procure the new business services provider and recruit the director of Fines Victoria in the earlier stages. It would then procure and implement a new IT system. This way, the program owners and users could become familiar with the new legislation, processes and IT system as they were being implemented and before VIEW went live.

While we considered the interdependencies between the different components of the fines reform program, our audit focused predominantly on the VIEW implementation project.

Upgrading the legacy fines IT system

DJCS was aware of issues with its legacy fines IT system, known as the Victorian Infringement Management System (VIMS), before the Victorian Ombudsman and the Sentencing Advisory Council criticised it in 2013 and 2014 respectively. By then, it had already begun an attempt to replace it. 

In 2007, DJCS contracted its long-term provider of fines business services to build a replacement for VIMS. This project failed, and DJCS terminated the IT system build contract in March 2015. By then, the VIMS replacement project had overrun by six years and cost $59.9 million—over twice the planned cost of $24.9 million. The service provider continued to support DJCS in its existing contract for business services.

This project failure meant that the commencement of the new fines legislation, originally planned for July 2016, had to be postponed until 1 January 2018. Following the termination of the build, DJCS added the procurement of a new IT system to the projects that were part of the fines reform program.

Driven by its new policy goals for the fines reform program, DJCS again planned to choose a new service provider to replace VIMS. It had identified that VIMS was outdated technology and that its functionality did not meet the requirements and goals of the intended fines legislative reform.

Lessons learnt

Following the earlier project's termination, DJCS assessed what went wrong to try to avoid repeating mistakes. It held two workshops (in May and November 2015) to review issues and developed a lessons-learnt report and presentation. The main lessons listed in the presentation and report were to:

  • allow enough time to undertake pre-procurement. Pre-procurement activities include completing a market assessment and confirmation activities
  • involve and empower key decision-makers
  • identify and analyse multiple IT options
  • ensure the business case is relevant, read and understood
  • ensure the scope is sufficiently defined, aligned, and managed
  • involve appropriate technological expertise
  • understand the relevance of technology to service provision
  • undertake a commercial analysis of all areas of procurement
  • adopt a suitable risk management approach.

1.2 Victoria's fines system

Scale of the fines system

Fines generate substantial revenue for the state and non-state enforcement agencies, such as local councils. The state retains fines and fees collected on behalf of Victoria Police. In 2019–20, the state revenue generated from fines and fees was approximately $830 million. In the same period, the state's fine revenue recovery was approximately $474 million.

Figure 1B shows FES revenue compared with its collection rate from 2013-14 to 2019-20.

FIGURE 1B: FES revenue compared to collected revenue

FIGURE 1B: FES revenue compared to collected revenue

Note: DJCS’s revenue and collection for the 2019–20 financial year were impacted by extenuating circumstances. Both the 2019 Victorian bushfires and the coronavirus (COVID-19) pandemic led to a reduction in fines issued, and enforcement agencies took additional steps to fairly issue fines and manage collection. These steps included:

  • Victoria Police delaying issuing new infringements to those directly affected by the bushfires
  • Fines Victoria placing a hold on existing fines and warrants for people residing within bushfire-affected areas
  • Sheriff’s officers pausing wheel-clamping across Victoria and not executing warrants in eastern Victoria
  • the suspension of Sheriff’s Office enforcement activities across Victoria in response to the COVID-19 pandemic
  • SMS and letter campaigns being suspended from March to June 2020 to provide relief to people affected by the pandemic.

Source: DJCS.

Fines Victoria undertakes significant work to administer the fines system. It processed approximately 2.1 million infringements in 2019–20. Due to its centralisation, the Victorian fines system is significantly larger and more complex than many other fines systems. It is common in other jurisdictions for individual councils, regions, or local government areas to manage their own infringement penalties using their own systems and processes.

Fines processes

The Victorian fines process is complex and has many steps—from issuing an infringement notice to the Sheriff’s Office enforcing a warrant. DJCS planned for some of the steps that enforcement agencies manually performed to be processed centrally and automatically using VIEW.

Figure 1C outlines the stages of fines processing in Victoria.

FIGURE 1C: Stages of fines processing in Victoria.

FIGURE 1C: Stages of fines processing in Victoria.

Source: Fines Victoria website, https://online.fines.vic.gov.au/The-fines-lifecycle, accessed 7 October 2020.

When an individual receives an infringement notice, they typically have 21 days to either pay, request a review, or nominate the responsible driver (for road-related infringements). Following a reminder notice period, if the debtor has taken no action, then the infringement will progress through the enforcement and warrant stages shown in Figure 1C.

In the enforcement stage, the director of Fines Victoria may impose administrative sanctions on the debtor, including:

  • directing VicRoads to suspend or not renew their licence or registration
  • making an attachment of earnings order, which is a court order that allows creditors to take money directly from a debtor's income
  • making an attachment of debts direction, which is an order that allows a person to recover money from a third party.

If an infringement is escalated to a court-issued enforcement warrant, the Sheriff’s Office has the power to:

  • immobilise and detain the debtor's vehicle/s
  • seize and sell the debtor's property
  • arrest the debtor.
Social justice initiatives

The fines system allows some concessions for those who may be unable to pay a fine. Prior to the Sheriff’s Office’s enforcement, an eligible party can apply for:

  • a work and development permit, which provides vulnerable people with a non financial option to deal with infringements
  • their fines to be withdrawn under the Family Violence Scheme, which applies if family violence substantially contributed to the offence or it is not safe for the debtor to name the responsible person.

The Time Served Scheme is another social justice initiative that enables prisoners to have a clean slate when they are released from prison in regards to fine debt. This supports their rehabilitation post-release and reduces the possibility of them being reimprisoned for an unpaid debt.

The complexity of the Victorian fines process and the need to accommodate initiatives like those above led to DJCS having many bespoke requirements for VIEW.

1.3 Roles and responsibilities

Department of Justice and Community Safety

DJCS's FES was set up to manage and enforce end-to-end fines processes for many agencies across Victoria. In January 2018, it also became responsible for court fines.


FES provides this service through Fines Victoria. The director of Fines Victoria is responsible for fines management and administrative enforcement. The Sheriff’s Office enforces and executes court-issued warrants.

Over 120 enforcement agencies, including Victoria Police, local councils, universities, and hospitals, are authorised to issue infringements. Some do not do so in practice. Others issue so few fines that they choose to enforce them themselves, including by initiating court proceedings for unpaid fines.

FES manages all stages of the infringement life cycle for Victoria Police and 15 other government agencies. Around 80 other enforcement agencies register fines with FES for enforcement and debt collection if they remain unpaid.

DJCS has previously been called the Department of Justice and the Department of Justice and Regulation. In this report, we refer to all iterations of the department as DJCS.

Department of Treasury and Finance

DTF oversees the application of the HVHR Project Assurance Framework and reports to the Treasurer.

Under the HVHR Project Assurance Framework, infrastructure and IT projects that are identified as being high value and/or high risk are subject to more rigorous scrutiny and approval processes. This includes project assurance checks and gateway reviews at key project stages. The goal of this process is to increase the likelihood that projects will achieve their intended benefits and be delivered on time and within budget. DTF is responsible for ensuring that agencies comply with the HVHR process if it applies to their projects.

As a high-risk IT project with a total estimated investment of over $10 million, the VIEW project is subject to DTF’s HVHR Project Assurance Framework. 

1.4 Legislative framework

The legislative structure that underpins Victoria's infringements system is provided by the:

  • Fines Reform Act 2014 (and its amending acts), which establishes Fines Victoria to administer fines and provides powers to the director of Fines Victoria to collect unpaid fines. The Fines Reform Act 2014 (and the authority of Fines Victoria) commenced on 31 December 2017 following multiple amendments
  • Infringements Act 2006, which establishes a framework for enforcement agencies to issue infringement notices. It also gives fine recipients the right to seek an internal review of these notices
  • Sheriff Act 2009, which outlines the Sheriff of Victoria’s powers and responsibilities, including the power to execute a warrant following the non payment of a fine
  • Road Safety Act 1986, which has provisions related to road safety offending and infringements.

Back to top

2. Developing VIEW

Conclusion

DJCS and the vendor knew by July 2017 they would not be able to deliver the required fines processing functionality by 1 January 2018, so they agreed to revised delivery time frames. Core functionality was to be delivered by the go-live date on 31 December 2017 with full functionality to be progressively implemented by June 2018.

But DJCS misapprehended the functionality that would be available at the go-live date. The vendor advised DJCS that VIEW would be 90 per cent functional, but a later analysis indicated it was only 5 per cent functional.

Full functionality will now not be delivered. DJCS decided in October 2019 that it would not deliver VIEW in the form it originally intended. 

2.1 Defining the VIEW project

New technology was a fundamental component of the fines reform.

DJCS intended for VIEW’s design to support the fines reform's policies and goals. Importantly, VIEW needed to draw together records from multiple agencies so that Fines Victoria could centrally manage infringements for the state.

The failure of DJCS's earlier IT project delayed the commencement of the new legislation and attracted public criticism, which led to significant pressure to get it right this time. From the beginning of the project, DJCS was also aware that its timelines would be tight.

DJCS therefore aimed to shorten the initial project phases to maximise the amount of time available for implementing the system. For this reason, DJCS procured an external IT advisor from an advisory firm to conduct preliminary market research into the availability of products that could suit its needs.

DJCS's previous IT system contract had been for a custom-built product. For VIEW, senior staff at DJCS were attracted to the time and cost savings that were typically offered by implementing a COTS product.

The IT advisor acknowledged DJCS's preference for a COTS solution and their recommendations aligned with this preference. The IT advisor drafted a report outlining the results of their market scan and recommended that DJCS save time by conducting a select tender to consider three shortlisted providers. Each of these providers offered a COTS product that the advisor assessed as being able to meet DJCS’s needs based on its product and vendor research. 

DJCS began the tender process in January 2016 and awarded a contract to its chosen vendor in September 2016. The contract specified a system go-live date aligned with the legislative commencement date of 31 December 2017.

2.2 Project governance

DJCS's key program oversight body throughout the project has been the Infringement Management and Enforcement Services (IMES) reform project steering committee (later renamed the FES reform steering committee).

DJCS set up the steering committee in March 2015 with a deputy secretary as the chair. The steering committee governed the whole reform program. Its responsibilities were:

  • guiding and overseeing the fines reform program
  • guiding and overseeing VIEW’s system development
  • procuring a new business services provider
  • resolving the existing system build and contract with the service provider
  • delivering support services to IMES to ensure business continuity
  • overseeing business transformation
  • implementing VIEW.

The chair reported directly to the Attorney-General on an as-needed basis rather than through DJCS's Secretary. 

Budget for VIEW

In DJCS’s August 2016 business case, the overall program budget included $26 million to implement the fines reform and establish Fines Victoria.

The capital budget for the VIEW project was $46 million plus a $3.8 million contingency. This consisted of:

  • approximately $20 million for infrastructure and licensing
  • approximately $25 million for service-related work.

2.3 Project timeline

Project timeline

*The functionality scores noted represent the 'functions' VIEW can perform as a percentage of the total required functions, and not the percentage of potential transactions. For example, some functions represent higher transaction proportions than others. While functionality has been increasing since 2018, VIEW is still not complete. DJCS has not quantified the current functionality level.
Source: VAGO.

2.4 System development

Multiple DJCS staff and contractors who worked on the VIEW project had also worked on the previous attempt to replace the IT system. This included the contracted IT advisor.

Changes in delivery deadlines

By July 2017, DJCS and the vendor realised they would not deliver the required functionality under the set timelines. As a result, they entered a contract variation. The variation, known as Deed 1, required a phased delivery of the system's functionality; core functionality was to be delivered by the go-live date on 31 December 2017 and full delivery of VIEW was to be progressively implemented according to an agreed schedule and completed by June 2018.

After July 2017, the vendor continued to not meet the set timelines and functionality delivery requirements. However, based on an assessment from its IT advisor, DJCS believed there was enough progress to continue. It decided to launch VIEW on the deadline with as much functionality as it could deliver by that date. The vendor and IT advisor told DJCS that it would deliver 90 per cent of functionality at the go live date.

Deciding on a backup plan

When DJCS and the vendor signed the contract in 2016, they had 15 months to implement the system.

When planning the VIEW project, DJCS had to decide whether to negotiate a longer contract with its existing service provider so it could continue to supply service and system support as a backup once the legislation commenced. 

Not extending the existing service provider's contract would mean that DJCS could not revert to using VIMS if there were issues with VIEW's implementation. Had DJCS wished to extend the existing contract, it was required to give six months’ notice before the contract end date of 31 December 2017. DJCS decided not to extend the contract at that time.

2.5 System go live

Following VIEW's launch, DJCS began to realise that the vendor had delivered substantially less functionality than it expected. Delivery of the remaining functionality was also slower than DJCS anticipated. In April 2019, a DJCS brief to the Attorney General stated that VIEW's functionality at the go-live date was only 5 per cent.

DJCS detected a significant number of system defects in VIEW in the weeks following the go-live date. It did not detect and fix all of these defects during the significantly compressed system testing process that occurred prior to the launch.

Figure 2A outlines the consequences of VIEW’s limitations at its launch in relation to the fines reform's objectives.

FIGURE 2A: VIEW's limitations identified following its launch in relation to the fines reform's objectives 

Fines reform objective Consequences of VIEW's limitations
Centralising the collection and enforcement of fines
FES managing and enforcing fines, including court fines FES was not able to send statutory notices to court fine recipients or enforce court fines. As a result:
  • DJCS did not collect court fine revenue from January 2018 to November 2019
  • fine defaulters who committed serious offences were not facing any consequences for their offending
  • the court system had reduced integrity
  • the number of community corrections permit applications reduced, which impacted Community Correctional Services’ workforce and ability to plan
  • court fines issued since 31 December 2017 were not progressing to warrants and could not be called in by prisoners under the prison program
  • court staff were managing more complaints and queries from fine recipients
  • re-hearing applications for courts increased
  • customer queries to the community sector increased.
Consolidation of a person's fines into a single account
  • FES cannot automatically identify and consolidate all of an individual's debts.
  • The ability to consolidate relies on the cooperation of the debtor to identify all their fines, but many are not willing or capable of doing so.
Shortening timelines as a deterrence
Streamlining of timelines and processes
  • Enforcement reviews and other FES processes had delays and backlogs.
  • Fines were not being enforced at projected levels.
  • FES was unable to report to agencies on the outcomes of enforcement activities.
More effective enforcement of unpaid fines through administrative sanctions
  • Administrative sanctions, such as licence and registration suspensions, were not applied.
  • New warrants were not being issued after 31 December 2017.
  • Sheriff’s officers had a reduced ability to conduct enforcement activities.
Improved social justice initiatives
  Work Development Permits, the Prison Time Served Scheme and Family Violence Scheme could not be fully managed in VIEW, requiring either manual workarounds or separate systems to manage, resulting in delays and backlogs.
Enhanced review processes
Review of enforcement orders Enforcement reviews took longer to conduct, which:
  • resulted in delays and backlogs with processing applications
  • reduced the integrity of the enforcement process because matters were on hold for extended periods while the review application was waiting to be considered. No enforcement action was taken in the meantime
  • made it harder to get responses from applicants to request further information because contact details provided with the application became outdated
  • increased the number of infringement matters listed in court.

Source: VAGO, based on information from DJCS. 

On VIEW's launch, DJCS had to carry out many functions and processes that were not yet available in VIEW using costly and time-consuming manual workarounds, which significantly increased processing backlogs. This impaired the integrity of the courts system and the Sheriff's Office was unable to enforce warrants for outstanding debts.

In the months following VIEW's launch, manual workarounds were required for tasks including:

  • payment receipts
  • the Work and Development Permit scheme
  • managing court fines (including receiving payments)
  • driver, vehicle and other sanctions
  • civil warrants
  • criminal warrants
  • enforcement warrants.

This contributed to the business services provider making processing errors, which led to incorrect handling of fines and significant media scrutiny. These errors resulted largely from DJCS's lack of clarity and understanding of new business processes.

2.6 Subsequent remediation

The VIEW project, like its predecessor, continues to face substantial implementation issues and delays. Following VIEW's launch, the vendor was unable to meet Deed 1’s phased delivery milestones to provide full functionality by June 2018.

In August 2018, DJCS and the vendor varied the functionality delivery timelines under the contract again. The second contract variation, known as Deed 2, specified new delivery milestones that aimed to fully deliver VIEW by March 2019. This did not occur.

Fines remediation program

In early 2019, DJCS engaged an external consultancy to review VIEW's delivery issues. It asked the consultancy to provide approaches to deliver a technology solution for implementing the fines reform.

As a result, DJCS established a fines remediation program, which aimed to mitigate risks and modernise Victoria’s fines system technology solution.

DJCS began the remediation program in June 2019. The program includes:

  • establishing the Fines Reform Advisory Board (FRAB) to independently review DJCS's plan for resolving the issues with VIEW and delivering the fines reform
  • developing workaround solutions to ensure DJCS achieves fines reform benefits and resolves technology solution issues
  • preparing a contingency plan
  • developing and progressing a business plan for the long-term stabilisation of VIEW and establishing a fully functional fines management technology solution.
Fines Reform Advisory Board

In October 2019, the government set up FRAB to:

  • advise the Attorney-General on whether the Fines Reform Act 2014 and related legislation are operating as intended
  • evaluate the interdependencies between the fines reform legislation, Fines Victoria’s operating model and VIEW
  • review the effectiveness of remedial actions taken to address issues with VIEW
  • review the forward plan to deliver an operating model supported by a fully functional IT system
  • determine if fines reform is meeting community and stakeholder expectations.

FRAB completed its review in April 2020 and provided its report to the Attorney General. The full report has not been publicly released. However, the government has released a summary report. The report provides 24 recommendations aimed at furthering the delivery of the objectives of the fines program. The government has supported 13 recommendations in full or in principle and will further consider the remaining 11 recommendations. The report found that there was still limited functionality for:

  • managing and collecting court fines
  • managing and executing warrants.

Despite this, it found that VIEW's functionality has improved with less workarounds, including:

  • new court-fine-related functionality
  • a reduction in the number of backlog matters, primarily for enforcement reviews
  • improvements in returns on council-issued fines
  • improvements in people’s ability to work off their fines.

FRAB found that DJCS continued to need manual workarounds for:

  • payment arrangements
  • processing enforcement review applications
  • supporting key social justice initiatives.

FRAB’s report states that DJCS’s remediation program ‘in its present form has appropriate business priorities and has shown progress in operationalising end to end system functionality’. However, it found that stakeholder and community engagement and backlog management needs improving.

The report states that payment rates of fines have increased since the fines reform and VIEW were introduced and now exceed pre-reform rates. However, reaching this point has taken a significant amount of time and money. FRAB made recommendations for DJCS to improve its governance and oversight, fairness and equity, decision-making and its remediation program and forward plan.

In October 2019, DJCS decided that it would not deliver VIEW in the form it originally intended. Instead, it is re-calibrating its technology needs to ensure a more sustainable system that better meets the long-term needs of the fines system. In the interim, DJCS and the vendor have continued work to increase VIEW's functionality to deliver it as a minimum viable product supporting the fines system.

2.7 Public reporting on the VIEW project

The Victorian Government IT Dashboard is a public website where the government reports the status of IT projects that cost $1 million or more. The dashboard now lists the VIEW project as completed, noting that delivery of remaining business functionality is continuing.
In March 2021, the public status report on the Victorian Government IT Dashboard had the project's status listed as 'red', or off track. It had had this status since mid-2018.

As reported in the Auditor-General's Report on the Annual Financial Report of the State of Victoria: 2019–20, DJCS has had difficulty since the introduction of VIEW in recording fines income accurately due to VIEW's lack of functionality. DJCS had to estimate fines income for financial reporting purposes. Using new reporting functionality implemented in 2019–20, DJCS identified significant financial reporting errors. DJCS understated the state’s fine revenue by $91.3 million in 2017–18 and then overstated it by $176.5 million in 2018–19. 

The original budget to build VIEW was $46 million. As at January 2021, DJCS stated that it has spent over $125 million developing and improving VIEW, as well as on workarounds where the system has lacked functionality. DJCS continues to incur costs as it looks to add functionality and finalise VIEW. 

DJCS also wrote off $20.8 million from VIEW's value in the 2018–19 financial year due to its lack of functionality. While the $20.8 million was already part of the project's total cost, the write-off demonstrates that DJCS's expenditure did not deliver the expected value.

Back to top

3. Governance failings

Conclusion

DJCS’s governance of the VIEW project was ineffective.

As a HVHR project, it represented a significant and material risk to the state. However, DJCS's governance arrangements, oversight and reporting were not commensurate with the importance and challenging nature of the project.

DJCS did not harness the required expertise, establish clear leadership, key roles and accountabilities, or adequately respond to DTF's gateway review findings. It also failed to fully inform the Attorney-General of the project's substantial risks and likely consequences.

3.1 Providing robust advice

In his August 2015 report, Learning from Failure: why large government policy initiatives have gone so badly wrong in the past and how the chances of success in the future can be improved, Peter Shergold found that Australian Government programs have been impeded by the Australian public service failing to provide robust advice: 

‘Public servants did not draw sufficiently on external views and expertise, and the partial evidence they did muster was unable to exert influence through its advice to ministers. There was a failure to provide sufficiently frank and forthright advice to ministers on important elements of policy design and risk. There was a significant gap between the inadequate levels of candour displayed in written advice and that reportedly conveyed in oral briefings’. 

We found that these findings apply to VIEW.

DJCS did not consistently ensure that the Attorney-General understood the project's risks. DJCS's briefings to the Attorney-General, particularly towards the system's launch, were overly optimistic and did not reflect the level of risk it faced.

In the early stages of the project, DJCS advised the Attorney-General of its concerns about setting a legislated commencement date for the fines reform without having procured or built the IT system to deliver the reform initiatives. However, DJCS did not present detailed or persuasive arguments to support its concerns.

The Attorney-General extended the timeline for the fines reform by 18 months. However, this was not as long as DJCS requested. Having not secured the time extension they sought, DJCS staff we interviewed said they felt that the delivery deadline was immovable. DJCS then focused on delivering VIEW and limited its upward reporting of risks.

In January 2018, the project team reported to the steering committee that project work for VIEW was 91 per cent complete. In a separate report that same month, the project team reported to the steering committee that ‘Phase 1 of the VIEW system, which included all mandatory functionality went live on 31 December 2017 as scheduled’. Up until late 2018, DJCS publicly reported VIEW's project status as 'green', which means 'on track' according to the Victorian Government IT Project Dashboard.

This reporting was inaccurate and misleading. In late 2018, DJCS changed VIEW's project status on the Victorian Government IT Dashboard from green to red with an acknowledgement of the project's significant delays and VIEW's lack of full functionality. 

In April 2019, DJCS reported to the Attorney-General that VIEW's functionality at its launch was less than 5 per cent. A March 2019 report by an external consultant determined that only 26 per cent of VIEW's requirements were fully functional 15 months after its launch.

Requests to extend project timelines

Early requests for an extension

From the early stages of the fines reform program, DJCS recognised that there was a real risk that it would not be ready to implement the required changes to the fines system, which largely relied on it implementing VIEW. 

DJCS briefed the Attorney-General three times to request an extension to the commencement of the new fines legislation. However, DJCS's briefs largely focused on other matters, such as changes to details within the legislation.

DJCS did not explicitly outline the challenges involved with procuring and implementing a complex IT system in the limited time available, the significant implications that delays in implementing the IT system would have on delivering the fines reform, or provide any alternate options to support the timely implementation of the key reforms.

In …

DJCS requested …

DJCS's brief …

DJCS's brief did not …

The Attorney-General …

May 2015

Delaying the new legislation's start date from 30 June 2016 to 30 June 2018

Stated that ‘the department has serious concerns about the ability to implement the substantive elements of the FRA [Fines Reform Act] on or by the current default commencement date of 30 June 2016’

DJCS expressed that it needed more time for:

  • policy development
  • extensive stakeholder consultation
  • procurement and delivery of the new IT system
  • analysis of issues with the previous attempted system build

Discuss in detail the issues regarding the IT solution, realistic timelines based on past government IT projects, any risks or likely consequences of retaining the original start date, or any alternate proposals

Returned the brief marked ‘please discuss’

June 2015

Delaying the new legislation's start from 30 June 2016 to 30 June 2018

Recommended the delay, stating that ‘the department has grave concerns about the level of risk involved in transitioning to the new fines recovery model by the current commencement date in the absence of both a new services agreement and an ICT solution’

Returned the brief marked ‘revised post AGO [Attorney-General’s Office] discussion’

July 2015

Delaying the new legislation's start from 30 June 2016 to 31 December 2017 Noted that the 31 December 2017 delivery date was optimistic and provided ‘limited scope for any contingency for delays in ICT development, software licencing and support issues, in addition to procuring and transitioning a new service delivery and support provider’

Approved the request and returned the brief marked ‘as many reforms as possible should commence on the originally scheduled date of 1.7.16’

After the Attorney-General granted an extension to 31 December 2017, which was six months less than DJCS's preferred start date of 30 June 2018, DJCS stopped seeking additional time. Former DJCS staff advised us that they had numerous verbal discussions about project timing risks with the Attorney-General’s office after July 2015, but the 31 December 2017 commencement date remained.

Staff we interviewed felt that DJCS had fulfilled its role by advising the Attorney General about the timeline risks and seeking extensions during the project's initial stages, and so concentrated on getting the job done. However, the three briefs DJCS provided to the Attorney-General did not inform them of the real risks and consequences in sufficient detail.

July 2017 draft request for an extension

In July 2017, some mid-level DJCS staff, who were aware of the issues involved with VIEW’s delivery, put forward options to the responsible DJCS deputy secretary to mitigate risks. This draft brief, which was intended for the Attorney General, explicitly warned that VIEW's delivery was at risk and recommended delaying the commencement date until December 2018, which would have been a postponement of almost a year.

The draft brief was detailed and stated that ‘the department considers there is a real risk that fines reform will not be delivered by 31 December 2017’ and that ‘risks and issues are developing and changing from day to day’.

The brief also suggested DJCS consider negotiating a new agreement with the existing service provider to provide services and support beyond the contract end date. The option to extend the existing contract had already expired.

DJCS advised us that this brief informed a discussion between the deputy secretary and the Attorney-General, but was not formally submitted to the Attorney-General’s office. Despite interviewing a range of senior staff, we found no record of the level of detail discussed during these conversations.

Approaching the go-live date

July 2017 advice on VIEW's readiness for go live

In early to mid-2017, DJCS's IT advisor assessed and reported on the vendor’s readiness for go live.

Although …

The IT advisor and vendor …

Based on this …

Timing for user testing was slipping

Asserted that VIEW would have 90 per cent functionality for the go-live date

 

DJCS's brief to the Attorney General in July 2017 stated that while there was a high risk that there would be insufficient time to conduct enough system functionality testing, VIEW was on track for delivery by 31 December 2017 with reduced functionality

The vendor was just beginning to develop new code very late in the project

The July 2017 brief expressed a ‘moderate level of confidence’ that ‘a pared back version’ of VIEW would be ready at the go-live date. However, without adequate testing, DJCS and the IT advisor could not be sure what level of functionality they would deliver.

The brief also noted that the project's risk rating had increased to high because it was likely there would be insufficient time for adequate staff training.

DJCS's advice to the Attorney-General was misguided and based on flawed reporting. We discuss this further in Section 3.2.

December 2017 advice on VIEW's launch

DJCS prepared a bill to amend the fines legislation to introduce some necessary administrative and social justice processes, such as assistance for those experiencing family violence. 

The bill included a deferred default commencement date of May 2018 to give DJCS the flexibility to delay launching VIEW. In December 2017, Parliament approved these amendments. However, DJCS decided to stick with the original launch date for VIEW. Internal DJCS documents state that it felt it was too late to delay VIEW's launch because it no longer had a contract to continue operating the existing VIMS system.

On 1 December 2017, DJCS briefed the Attorney-General again. While noting the option of a May 2018 commencement date and that the project risk rating remained red, DJCS recommend that the Fines Reform Act 2014 be proclaimed to commence on 31 December 2017 as originally intended.

It listed the following reasons:

  • The vendor expressed confidence that it could deliver essential VIEW functionality by 31 December 2017.
  • The user acceptance testing conducted so far had not identified any critical system issues that would hinder VIEW's launch.
  • Staff training, though limited, was progressing well.
  • DJCS's contract with VIMS's provider would conclude on 31 December 2017. This meant that not going live with VIEW would require urgent negotiations to extend the use of VIMS. DJCS believed this would be costly and complex.

In a 29 December 2017 brief to the Attorney-General, DJCS also expressed confidence in VIEW going live despite the risks of defects occurring. The optimism in this brief reflects the positive reporting that DJCS received from its IT advisor and vendor about the high level of system functionality expected at VIEW's launch. 

In this brief, DJCS also reported that VIEW's infrastructure was in place, tested and ready for launch. This was not correct. The brief noted some areas of risk and remaining issues, but that Victoria Police was comfortable with VIEW's functions for processing its fines. It noted that the launch would take place as planned and that briefings on its functionality would continue after the launch. The Attorney-General did not sign this brief to acknowledge its receipt.

While DJCS noted that VIEW's project status was rated as red, it did not report on the potential financial implications and social consequences of the launch failing. The December 2017 briefs did not highlight the risks from the incomplete testing undertaken, the lack of clarity over VIEW's available functionality or the lack of a contingency plan should VIEW fail. DJCS's internal December 2017 overview of VIEW's functionality showed it would need a significant number of workarounds at its launch. DJCS did not communicate this lack of functionality to the Attorney-General.

3.2 Accountability for delivering VIEW

In March 2015, DJCS established a project steering committee to oversee the progress of the fines reform program, including VIEW's implementation. The steering committee met monthly in the project's early stages and increased this to fortnightly in the lead up to the go-live date.

The governance model meant that the steering committee reported directly to the Attorney-General, not through DJCS's secretary. This reduced oversight by DJCS's executive. This structure allowed risks to VIEW's implementation to escalate with limited review.

DJCS's audit and risk management committee also did not keep track of VIEW's progress. DJCS only escalated VIEW's risk of implementation failure to DJCS's corporate risk register in September 2019, which was nearly two years after the delivery deadline.

The steering committee allowed milestones to slip and many project risks to go unacknowledged and/or unaddressed. These are detailed in Chapter 5 of this report.

A Go/No-go report is a mid project analysis of progress to recommend whether or not to proceed to implementation or proceed with caveats.

The steering committee's meeting minutes do not detail in-depth discussions or considerations of key reports, such as DJCS's report on lessons learnt from the previous VIMS project and the ‘Go/No-go’ report, and their implications for the project. Therefore, it is unclear how seriously the steering committee considered these reports and their advice.

Steering committee oversight and capability

Steering committee membership included DJCS's deputy secretary of criminal justice as chair, representatives from IMES, DJCS's chief procurement officer, a director from DTF and DJCS’s contracted IT advisor. It was also supported by external consultants with expertise in various areas, including contracts.

Skills mix and independent representation

Six of the 12 people involved with the steering committee that we interviewed felt that it had a good mix of business representatives and technical expertise. However, the other six people expressed concerns that the steering committee:

  • had lacklustre decision-making capacity
  • failed to challenge advice
  • did not often discuss the technical aspects of VIEW's delivery in detail.

The steering committee lacked IT project management expertise. When procurement decisions were being made, there was no independent IT specialist on the steering committee to help develop options. This is likely to have contributed to DJCS's heavy reliance on the IT advisor, who was subsequently tasked with multiple conflicting roles across the project. This is discussed further in Section 5.5.

The IT advisor was hired to conduct the pre-procurement phase of the project and then retained to assist the steering committee. While the IT advisor did not have formal IT qualifications, they had prior experience in IT system development for government agencies.

In December 2015, a gateway review said that the steering committee lacked the capacity to oversee the project. It recommended adding skilled IT experts to the committee to address this. Following this recommendation, the steering committee sourced an additional IT expert as an independent member but continued to rely heavily on the existing IT advisor.

DJCS should have identified the need for independent steering committee membership to test and challenge decisions from the outset. The steering committee would have benefited from independent expertise at an earlier stage when it made key decisions about the project’s direction.

The December 2015 gateway review also found that the steering committee was poorly constituted because the committee's members, including the project director, IT advisor and others, were involved directly in the project's delivery. This diminished the role of the steering committee in providing objective oversight of the project's progress and properly debating and challenging critical decisions. In response to the review, DJCS updated its governance charter in September 2016 to clarify the committee's membership, roles and responsibilities. However, the IT advisor and the project director continued to appear regularly at the steering committee meetings as attendees and advisors.

After appointing a new deputy secretary to oversee the fines reform in February 2019, DJCS recognised that the steering committee was not meeting its needs for fines reform governance. In particular, DJCS determined that the committee was too narrowly focused on implementing VIEW in isolation of how the other various reform elements interacted within the broader program.

In an August 2019 review, DJCS also noted that the steering committee and project governance groups supporting the steering committee had evolved and narrowed over time to mainly include IMES executive participants with reduced participation of members with technical expertise after VIEW's launch.

Lack of steering committee chair and member continuity

The steering committee also lacked continuity of membership. There were multiple changes in committee members and its composition, project staff and leadership throughout the project. This reduced the committee's authority for and oversight of the project and led to instability and a lack of continuity in decision-making and direction.

Some members of the steering committee did not always consistently attend meetings. Sometimes members sent delegates in their place, which interviewees said reduced the committee's decision-making authority and the detail of some conversations.

There were 43 steering committee meetings in the 21 months leading up to VIEW's launch. During that time:

  • the executive director was an apology for seven meetings, including three meetings in the six months leading up to the go-live date
  • two other DJCS steering committee members attended between 50 and 70 per cent of meetings, and usually did not send a delegate when they were unable to attend
  • Victoria Police was represented by five different members, with the attendee often being a delegate or acting in their role. Even so, Victoria Police had no representation present at 11 of the meetings.

Misleading and overly optimistic reporting

While the steering committee received regular and detailed reports from multiple sources, the key reports it used for decision-making and briefing upwards did not accurately present VIEW's progress. This meant that the steering committee’s advice and decision-making was ill-informed. It also contributed to the steering committee overestimating VIEW’s functionality and readiness for launching and DJCS's inaccurate advice to the Attorney-General.

DJCS's internal project team's reporting to the steering committee was inconsistent. For example, in December 2017, the project team changed the internal project risk rating from green to red to reflect the risk posed by the limited time available to test VIEW before its launch. At the same time, the project team reported to the steering committee that the project's overall completion was at 89 per cent. This was despite the fact that no end-to-end testing of the system had occurred. The project team did not explain the basis for their assessment and the steering committee did not query this inconsistency.

3.3 Gateway review process

DTF’s HVHR framework requires agencies to arrange for external reviewers to conduct gateway reviews. While DJCS participated in gateway reviews of VIEW, DJCS’s limited response to the reviews and the weaknesses in the gateway review process itself reduced its effectiveness to support the project's governance and success.

Risks not communicated to DJCS's senior management

DTF's guidance states that gateway reports are distributed to the project's SRO and it is up to them to distribute reports further. The intent of this is to encourage the SRO to openly engage with the review process without fearing the consequences of negative findings. DTF's guidance also states that '[a]s part of good practice however, distribution of the Gateway report by the SRO to the project steering committee (or equivalent) is recommended’.

VIEW's SRO did not provide the gateway reports to the project steering committee or DJCS's executive. This meant that serious issues identified in the reviews were not communicated to a sufficient level of seniority in DJCS for appropriate action to be taken. This limited DJCS’s ability to oversee the project's performance and hindered the gateway reviews' function to raise issues early.

DTF has good intentions in providing advice to SROs confidentially to encourage open disclosure of project issues. However, doing this can prevent shared awareness of issues with those ultimately accountable for a project. The risk of an SRO not disclosing problems to reviewers for fear of potential repercussions would be better addressed by supporting the public sector to deal with project problems in a more mature and no-blame approach.

This issue may have also been avoided if the SRO had been someone at a more senior level. DTF's guidance defines the SRO as ‘[t]he person in the client organisation who is ultimately accountable to Government for the successful delivery of the project’. Its guidance recommends that the SRO should be an executive director or deputy secretary. However, the SRO for the VIEW project was more junior than the deputy secretary who was accountable for the project within DJCS. 

DTF only briefs the Treasurer on high-risk recommendations from gateway reviews. We found that reviewers rated some recommendations for the VIEW project as medium risk that we consider should have been rated as high risk due to the high likelihood of the project not meeting its timelines. 

There is no HVHR requirement for an SRO to provide a recommendation action plan to the Treasurer for resolutions except for red-rated risks. The VIEW project's gateway review process would have been more effective if its SRO was accountable to DJCS's executive for lower rated risks. A former deputy secretary and steering committee chair we interviewed had similar concerns about the gateway review process.

DTF advised us that the intent of the gateway review process is to undertake a short and sharp review at a point in time. The reviews are not meant to be audits or replace an agency’s oversight measures. However, this does not negate the expectation that reviewers highlight all risk areas and require their rectification.

Issues identified in gateway reviews that are not expressed as recommendations do not need an action plan and DTF is not required to do any further reporting on them, which increases the risk that they will not be addressed. Gateway reviewers spoke to some issues with the VIEW project in their reports but did not raise them as risks or make recommendations. DTF argues that some issues identified by reviewers in Figure 3A, such as the quality of the business case, had improved by the Gate 4 review. The early gateway review findings reflect serious shortcomings in project planning and the reviewers should have emphasised them. Figure 3A shows examples of issues that the reviewers did not formally highlight as risks with recommendations.

FIGURE 3A: Issues noted in gateway reviews that should have been raised as risks with recommendations communicated to senior decision-makers

Gateway report Gateway report statement Why it should have been raised as a risk with a recommendation
Gates 2 and 3 The gateway review noted that 'whilst the business case is compliant with the Victorian Government standard template, it reads as a justification of a preferred solution. The business case lacks detail and analysis expected of a complex IT acquisition with the potential for an 18-year asset lifecycle’. This should have been a red flag that the project had not been sufficiently scoped and planned.
The gateway review stated that the project had not taken a high-level analysis of the requirements of each of its major stakeholders and the need to integrate their existing systems, business rules and processes into the acquired COTS solution of the VIEW system. A detailed understanding of stakeholder requirements should have been completed to inform the project. Its absence should have been highlighted as a risk.
Gate 4 The contract provided to the reviewers was close to completion. The reviewers were advised that not all of the schedules within the contract were to be completed prior to the contract being signed. However, a number of critical schedules were still being negotiated (for example, schedule 7 of the Service Levels and the Data Conversion Plan). The lack of critical requirements prior to the commencement of the procurement process (let alone the contract completion) should have alerted the reviewers to the insufficiency of DJCS’s project planning and understanding of business requirements. 

Source: VAGO analysis of VIEW’s gateway reviews.

DTF also undertook a separate PAR, which it completed in August 2018. However, by the time it conducted this review, VIEW was live and many of the risks previously identified had already eventuated. 

DTF began using PARs for HVHR IT projects from 2016. PARs are designed to provide timely and independent advice to an agency and DTF on the readiness of a project. A PAR is triggered when a project is experiencing problems or requires an expert review. 

VIEW passed the combined gates 2 and 3 review in December 2015, which was before DTF started conducting PARs. DTF undertook more gateway reviews in September 2016 and December 2017. A PAR conducted on VIEW in mid-2017 could likely have further highlighted the risks to VIEW’s launch. However, the DTF staff involved in VIEW’s gateway review process did not recommend it for a PAR. 

DJCS did not address all findings and recommendations

DJCS did not address some amber-rated risks identified in the gateway review process, which allowed the issues and associated risks to continue or recur. Despite having a section to provide an update on previously reported risks, the gateway reviewers did not highlight the continued recurrence of risks in their reports. Figure 3B shows examples of risks that DJCS did not address, which later manifested as issues.

FIGURE 3B: Gateway report risks that DJCS did not address

Initial gateway report finding Risk implication Recurrence of finding Further recurrence
Risk—lack of an approved benefits management plan with buy-in from key stakeholders and process owners
Gate 4: September 2016 
The benefits realisation plan had not yet been developed. A high-level overview of the project’s benefits was documented in the business case though.
Benefits needed to be clearly identified and planned for early so the delivery could be managed in a way that optimised their realisation.
There was a lack of clarity about:
  • the actual benefits the new system was going to introduce
  • how to measure and report on whether the system was meeting its intended goals and benefits.
Gate 5: December 2017
The IT advisor had prepared a benefits management plan for the fines reform program. However, the review team understood that this was yet to be committed to by benefits owners and signed off by the SRO.
DTF’s PAR: August 2018 
This review raised the project’s lack of a finalised benefits realisation plan as an issue again(a).
Risk—project team having an inadequate understanding of the major stakeholders’ detailed requirements, and a lack of positive stakeholder involvement
Gates 2 and 3: December 2015
The project had undertaken a high level analysis of the requirements of each of its major stakeholders and the need to integrate their existing systems, business rules and processes into the acquired COTS solution(b).
Without a detailed scoping of stakeholder needs, DJCS could not be sure it had an adequate understanding of the project’s requirements to inform the procurement process and delivery. Gate 4 review: September 2016
Some stakeholders identified poor stakeholder engagement. They were particularly concerned that some crucial legislative impacts on their business would incorrectly be considered out of scope or not sufficiently understood by the program.
Gate 5 review: December 2017
The previous review team noted that a number of interviewed stakeholders felt under engaged with and needed a broader range of engagement approaches. This review found that some stakeholders still felt unengaged.
 

Note: (a)DJCS only approved the benefits management plan in May 2019. 
(b)This issue was included in the body of the gates 2 and 3 review, but not raised as a recommendation to address.
Source: VAGO analysis, based on VIEW’s gateway reviews.

Timing of gateway reviews

Gateway reviews are meant to support the decision-making process, such as informing the decision to go to market or whether to fund the project. The timing of the VIEW project’s gateway reviews created a 15-month gap between the gateway review to support the tender decision (Gate 4 in September 2016) and the review to inform VIEW’s readiness for service (Gate 5 in December 2017). By the time the Gate 5 review was complete, it was too late to address the risks that had unfolded between gates 4 and 5.

The Gate 5 review in December 2017 occurred three weeks before DJCS launched VIEW. Despite DTF engaging DJCS three months before the planned launch, DJCS initiated the review extremely late in the process. The reviewers recognised the timing issue and said the review had occurred 'effectively after implementation decisions had been taken'. The late timing of the review limited the impact that the review could have had on the project.

It is the project owner’s responsibility to contact DTF's gateway unit to initiate a review. The timing of reviews should allow enough time to address concerns raised by the reviewers. VIEW’s SRO did not initiate the review early enough for the resulting recommendations to have an impact. While gateway reviews are not meant to replace project management structures, the timing of VIEW’s gateway reviews did not support timely risk mitigation, which is their purpose.

Other gateway review limitations

Gateway reviews are limited depending on the experience level of the reviewers. They may fail to address the root cause of an identified risk if the reviewers rely on basic templates and verbal evidence to make their assessments. VIEW’s gateway reviews did not always focus on significant risks or hold DJCS accountable for mitigating the risks the reviews identified.

An example of this is in the risk management assessment in Gate 4. Figure 3C shows the gateway risk management questions.

FIGURE 3C: Gate 4 risk management questions 

Item Areas to probe
4.1 Are risk and issue management plans up to date? Are they being monitored?
4.2 Have all major risks that arose during this stage been resolved?
4.3 Are arrangements in place to minimise risks to the business in the event of major problems during implementation and rollout?
4.4 Does the contract reflect the standard terms and conditions and the required level of risk transfer?
4.5 For longer term partnering contracts, have the re-tendering issues been considered?

Source: DTF’s Gate 4 guidance.

The Gate 4 report for VIEW stated that:

‘The Risk Register is regularly updated and is currently the subject of a detailed review. Interviewees noted the intent to utilise a combined State and Supplier risk register to ensure that status reports reflect vendor perspective.

They see the risk register as a reasonable representation of the current risks but highlighted that the program is high risk today and so will require close control. They observed that the long-term application of mitigation strategies should see risks reduced to an acceptable level.

The Review team did not sight an Issues Log. Interviewees see the highest project risks as being the aggressive schedule required to achieve go-live on 31 December 2017 and data migration’.

The Gate 4 report mainly refers to evidence that the project had a risk management process, rather than assessing its key risks and whether they were being effectively mitigated. The gateway reports also recount interviewees’ perspectives, rather than providing an independent assessment of the risks. Without a substantive and independent analysis, gateway reviews will fail to identify and highlight key project risks and their root causes for future HVHR projects.

Back to top

4. An uninformed buyer

Conclusion

DJCS’s staff and consultants who were involved in procuring VIEW lacked the technical capability to undertake the task. They either did not recognise or did not acknowledge this issue and therefore failed to mitigate it.

As a result, DJCS did not have a detailed understanding of its requirements for VIEW prior to engaging the vendor and was unable to clearly communicate what it wanted the vendor to provide. It was also unable to adequately assess the suitability of potential vendors.

Consequently, DJCS selected a product that did not fit its needs, has required significant modification, remains incomplete and is not yet delivering all of its intended benefits.

4.1 DJCS’s procurement approach

Bias based on previous experience and time constraints

DJCS's approach to procuring VIEW was in part moulded by its experience during its previous attempt to replace VIMS. The previous attempt had sought to build a customised product to meet the needs and business processes of the unique and complex Victorian infringements system. The failure of that project highlighted the complexity and time-consuming nature of building a custom IT system.

After this, some senior stakeholders and staff at DJCS were resistant to attempting to develop another custom-built system. Staff advised us that the key lesson from the previous project was to avoid another full system build. This belief was based on an over-generalisation of the problems with the previous project.

DJCS favoured choosing a COTS product, which it believed would involve a simpler implementation with time and cost benefits. This preference was well known by staff working on the project who we interviewed, and the preference affected DJCS's decision-making process.

As a result, DJCS limited its consideration to options it felt could be delivered within the set time frame. It did not consider a broader range of options, such as:

  • a custom solution
  • other IT option types, including cloud solutions
  • wider solution types, such us outsourcing fines processing to a third party.

DJCS believed a COTS system was the most efficient way to meet its deadline. It chose a procurement strategy in line with this outcome, despite not fully considering whether a COTS product could deliver the fines reform’s complex requirements.

Lessons 'learnt'

After ending its earlier attempt to build a new fines system, DJCS assessed what went wrong to try to avoid repeating similar mistakes. It produced a report on lessons learnt to accompany the project closure documents. The report found that many of the project’s difficulties originated in the pre procurement and conceptualisation stages, which took place in late 2006.

The report refers to VAGO's 2008 Investing Smarter in Public Sector ICT: Turning principles into practice and states that many of the key lessons learnt from the earlier project are consistent with VAGO’s guide, including:

  • getting all the right people involved in designing the project
  • making allowances for your own optimism bias or that of the chosen supplier
  • being an informed buyer.

The report concedes that DJCS did not engage appropriately skilled technical people who could understand the challenges of procuring a bespoke IT system. It also stated that DJCS ‘was far from being an informed buyer of these services'.

The report also noted the impact of how DJCS structured the previous contract with its service provider, which made it difficult for the parties to terminate it. Based on our interviews with staff involved in the VIEW project, this lesson became a focus for VIEW. DJCS’s focus on setting up the vendor contracts and on avoiding another complex project caused it to overlook the other key lessons. This led to problems recurring in the development of VIEW.

There is also an extensive body of academic literature that DJCS could have drawn on to improve its understanding on a much broader range of technology project failures and how to avoid them.

Limited market analysis

DJCS initially engaged its contracted IT advisor to conduct a market scan to consider available suppliers and technology, market trends and factors that could influence price. The goal was to determine whether the market was likely to provide a vendor and product that could meet DJCS’s needs and whether it could do so straight ‘out of the box’ or with limited customisation.

DJCS directed its IT advisor to consider its preference for COTS systems during their research. It also emphasised to the IT advisor the importance of the delivery deadline. As a result, the IT advisor did not recommend solutions or providers that indicated they could not meet the requested timeline—they were considered high risk and set aside.

This limited the extent to which the IT advisor and DJCS explored alternative options. The IT advisor acknowledged DJCS’s preferences and their July 2015 market scan report identified and analysed 49 vendors and products. It shortlisted three providers with COTS products that the IT advisor assessed as likely to be able to meet DJCS’s needs.

DJCS’s decision to prefer only COTS products and vendors who could meet its tight deadlines narrowed the range of vendors it could choose from. This reduced the competitiveness of the process and potentially tainted the objectivity of the IT advisor’s market scan. It also reduced the incentive to assess the shortlisted vendors as unsuitable in the following assessment phase because to do so would mean having to restart the procurement process.

Pursuing an outdated solution

By focusing on pursuing a COTS system, DJCS limited itself to what is considered outdated technology.

DJCS did not contemplate technology that would support a SaaS option, which reflects a more contemporary approach. By choosing a COTS solution, DJCS placed itself in the ‘laggard’ (or lagging) segment of the technology adaption life cycle, as Figure 4A illustrates.

This further demonstrates DJCS’s lack of IT market and technical understanding. Even within the IT field, it is challenging for individuals to maintain expertise due to the fast pace of progress. Consequently, public servants need to be aware of the potential that their ‘expert’ may lack the most up-to-date knowledge.

FIGURE 4A: Technology adaptation lifecycle

FIGURE 4A: Technology adaptation lifecycle

Source: VAGO, based on Geoffrey Moore, Crossing the Chasm, 2014.

Lack of sufficient understanding of business requirements

DJCS's decision to exclusively seek a COTS product also demonstrated that it lacked a full understanding of, or was in denial about, the unique and complex elements of the Victorian fines system, especially the technical requirements necessary to deliver a debtor-centric system. Figure 4B illustrates the complexity of the Victorian fines system’s requirements for an IT solution.

FIGURE 4B: The complexity of the Victorian fines system’s requirements for an IT solution

The Victorian fines systems brings together multiple agencies and requirements, which makes managing and processing fines extremely complex.

A successful IT solution that could manage the Victorian fines system in its totality, as envisaged, would need to deal with approximately:

  • 120 enforcement agencies
  • six million infringements lodged each year
  • infringements contained within 60 statutes
  • 50 external interfaces
  • 100 agency inputs
  • 52 types of infringement notices
  • 800 types of documents.

Source: VAGO, based on DJCS's procurement documentation.

COTS products are typically developed to cater to a broader market with less bespoke needs to maximise their customer numbers and profit. The existence of a COTS product in the market that would be able to meet all of DJCS's specific needs was extremely unlikely.

The IT advisor’s pre-procurement market research failed to understand and identify this. Instead, it assured DJCS that there were likely multiple products available in the market that could meet its needs.

While procuring the vendor for VIEW, DJCS was simultaneously developing and amending the legislation for the fines reform, considering how to operationalise it, revising its business processes to suit, and establishing Fines Victoria. DJCS subsequently struggled to focus on and confirm the business requirements for its desired IT solution as changes were occurring in parallel.

Engaging stakeholders to determine their functionality needs

DJCS did not have a sound understanding of each enforcement agency’s business needs, systems or processes before it approached the market and conducted its market assessment and tender evaluation. This made it difficult for DJCS to properly specify the requirements of the system and assess if a vendor and product could meet its needs.

For example, certain infringements that involve a person losing their driver license can only be reviewed, processed, or withdrawn by a member of Victoria Police and within a certain time frame. This means that any business process requiring a public servant or contracted service provider to conduct a review would be illegal. This was only highlighted to the steering committee in March 2018 after VIEW launched.

Poor articulation of requirements to vendors

DJCS did not clearly state VIEW’s expected functionality and outcomes from the project’s outset. The system requirements that DJCS provided to the bidding vendors during procurement were partly based on the requirements developed for the previous system, which had a different set of intended benefits. These requirements were therefore inconsistent with all of those needed for VIEW.

The IT advisor contributed to drafting these requirements and later conceded that they were outdated, incomplete and to an extent, misleading. The vendor advised us that in its opinion, the requirements it received were poorly detailed and incorrectly specified. Representatives of the vendor told us that had they known the complexity of DJCS’s requirements up front, building a system from the ground up would have been a better approach than starting with a COTS system and customising it.

Subsequently, the extent of changes to VIEW’s system requirements was the subject of a dispute between the vendor and DJCS, with each party disagreeing on whether some requirements were original, clarifications or new. The dispute did not proceed to litigation and was settled by an agreement in mid-2018.

The fact that DJCS did not clearly specify its requirements contributed to the vendor's poor understanding of the project’s complexity. Consequently, in the later stages of the project, the vendor had to quickly scale up to complete a huge amount of unanticipated coding work that left VIEW difficult to test and upgrade.

A constrained tender process

DJCS's IT advisor recommended conducting a shorter procurement by considering only selected vendors. Based on this advice, DJCS sought and obtained the government’s approval to conduct a select tender that only considered the three vendors that were shortlisted in the market scan. While the select tender streamlined the procurement process, it limited the number of vendors that DJCS considered and relied on there being suitable products already available in the market. Despite this, the procurement and vendor selection process still took over a year.

DJCS's IT advisor and some DJCS staff advised us that they hoped the potential vendors would push back on the length of time that DJCS had allocated to deliver the system. Because DJCS did not feel in control of the project timelines, staff wanted to use vendor feedback to strengthen its requests to the Attorney-General for an extension.

Unsurprisingly though, vendors submitted bids in line with DJCS's requested date. Only one potential vendor included a second tender option with a later delivery date and a lower cost. DJCS’s evaluation team rejected this option from consideration because the vendor in question had not provided the documents that were required as part of the tender process for that bid. DJCS only included vendors that agreed to the 31 December 2017 deadline in its final negotiations. Potential vendors had to either accept the risk of the compressed timelines presented to them and try to resource accordingly or opt out.

4.2 Vendor and product selection

Assessing the vendor offerings

DJCS set evaluation criteria to fairly compare the potential vendors. DJCS's IT advisor helped generate the criteria.

Weighting the evaluation criteria

DJCS’s weighting of the tender evaluation criteria did not prioritise some elements that were needed to meet the fines reform's goals.

The criteria weighting emphasised the ease of dealing with the vendor at the expense of more fundamental technical elements. This is reflected in the vendor criteria category shown in Figure 4D, where ‘in-project capability’, ‘support capability’, ‘innovation’ and ‘customer service’ account for almost 37 per cent of the total score.

DJCS inadequately weighted elements of the business case that were integral to meeting the fines reform's requirements, including configurability to meet future needs, interfaces, the reporting functionality to allow DJCS to meets its reporting obligations and the need for the system to be debtor centric. Each of these important functions accounted for less than 5 per cent of the overall evaluation:

  • debtor centricity accounted for 3.91 per cent
  • interfaces accounted for 2.3 per cent
  • reporting accounted for 3.18 per cent
  • correspondence accounted for 2.65 per cent.

While the importance of debtor centricity as a goal of the fines reform was apparent to the staff and stakeholders that we spoke to, DJCS did not emphasise it in its procurement process and tender evaluation. As a result, the system that was developed overlooked this key requirement until very late in the process.

Figure 4C shows the two finalist vendors' scores in DJCS's system functionality categories.

FIGURE 4C: Vendors' system functionality scores

Functionality element Maximum score available for element Chosen vendor Other vendor
Score % of maximum Score % of maximum
System functional score 44.20 27.97 63.3% 27.94 63.2%
Common processes (including debtor centricity and end-user configuration) 12.60 7.36 58.4% 8.00 63.5%
Enforcement 6.40 4.00 62.5% 4.00 62.5%
Infringements 8.40 5.50 65.5% 5.50 65.5%
Inputs and outputs (reports, correspondence, interfaces, web portal) 12.60 8.33 66.1% 8.02 63.7%
Warrants 4.20 2.78 66.2% 2.42 57.6%

Source: VAGO, based on information from DJCS.

If DJCS’s evaluation criteria had prioritised other important elements, it is possible that the other vendor’s overall score may have been higher. Components of the common processes category, such as debtor centricity, were critical for achieving DJCS’s intended fines reform benefits. Components of the system technical category, such as scalability, were important given the significant difference in the number of transactions required by Victoria’s infringements system compared to other jurisdictions. This issue is discussed further in the next subsection.

While the two vendors had close scores against the 'system functional' element, the chosen vendor’s overall score was higher once other aspects were factored in, which Figure 4D shows.

It is likely that DJCS's poor experience of working with the previous service provider led it to place more importance on the ease of working with the vendor.

Figure 4D shows the two finalist vendors’ overall assessment scores.

FIGURE 4D: Vendor overall scoring

Element Maximum score available for element Chosen vendor score Other vendor score
System technical category score 63.20 40.71 39.93
System functional 44.20 27.97 27.94
Data conversion 12.00 8.66 7.54
System technical 7.00 4.08 4.45
Vendor category score 36.80 24.84 21.72
Customer service 2.00 1.40 1.40
Innovation 5.00 4.00 3.00
In-project capability 16.80 11.47 8.97
Support capability 13.00 7.97 8.35
Total 100.00 65.55 61.65

Note: This figure contains two variations from the scores listed in DJCS’s VIEW System Evaluation Report. The report lists the chosen vendor’s system score as 40.17 and its grand total score as 65.54. DJCS has confirmed that these were input errors and the above figures are correct. The variations are not significant enough to have affected the final result.
Source: VAGO, based on information from DJCS.

IT advisor's assessment

In their market scan, DJCS’s IT advisor scored the functionality fit of the three shortlisted vendors as between 86 and 92 per cent, with the chosen vendor assessed as an 86 per cent fit at this stage of pre-procurement. However, in the final evaluation report, the chosen vendor was given a system functional score of 63.3 per cent and the remaining competitor was rated 63.2 per cent, as outlined in Figure 4C.

One of the main reasons the IT advisor shortlisted these vendors was their apparent ability to meet DJCS’s functional requirements within its deadline. While the scoring systems across the different procurement stages were different, the final scores do not clearly show that either of the systems in question could meet DJCS’s needs without customisation.

The scoring method was designed to indicate if the vendors could provide functionality without customisation. The evaluation report explains that a score of 50 per cent means that the product can meet all functional requirements, but would require customisation to do so, whereas a score of 100 per cent would mean all functional requirements could be met 'out of the box'. However, it is not clear from the results which requirements or how many of them fell below thresholds that would therefore require customisation. For example, it is difficult to tell if either of the final solutions could meet the fundamental requirement of being debtor centric without customisation.

The IT advisor's evaluation report to DJCS stated that '[a]s a rule of thumb, due to this method of scoring, any score exceeding 50 per cent should be considered a very strong offering’. 

We have not been able to substantiate the rationale for this assessment through the evidence we received. Given DJCS's desire to avoid significant product customisation, the shortlisted vendors’ failure to closely meet DJCS’s requirements without customisation clearly indicated that they did not truly have COTS products that were ready to meet Victoria’s fines reform’s needs. This should have caused DJCS and the IT advisor to re-evaluate the business case and review the project timeline. The fact that this did not occur indicates that there were capability gaps in DJCS’s IT expertise, procurement and project oversight.

DJCS did not question the IT advisor's advice or address the shortlisted vendors’ gap in the expected level of technical fit. DJCS did not question the difference between the proposed degree of fit stated in the market scan and the reduced degree of fit indicated in the tender evaluation report.

As the tender evaluation report may have predicted, the selected vendor's product turned out to have a poor degree of fit and required a high degree of customisation to deliver VIEW. The vendor’s claim for compensation in 2018 stated that it had incurred an additional 30 000 days of effort above its development budget. This points to a flawed assessment of the suitability of the vendor’s product.

Appropriately scrutinising vendors

International vendor site visits

Following the market scan, the IT advisor recommended that they lead market confirmation activities on behalf of DJCS. These activities sought to test and confirm the advisor’s market research findings by more directly engaging with the shortlisted vendors.

DJCS obtained the government’s approval to send an evaluation team on an international trip to conduct site visits of the shortlisted vendors.

The international site visits to the United States of America and the United Kingdom gave the evaluation team the opportunity to observe the products in place with other customers, consult the shortlisted vendors and confirm if they could use a select tender. While the shortlisted vendors did not have a strong presence or customer base in Australia, we note that the selected vendor does not appear to have had a strong base for the product it was offering in other markets either.

DJCS outlined the planning for its site visits in its brief seeking approval for the trip. The brief was not detailed. It did not address:

  • how the procurement approach would be validated and progressed
  • how agencies impacted by the project would be adequately represented
  • how the visits would confirm the market scan report’s findings and that the available products were a good match for DJCS’s needs
  • the skills the participants required to undertake the assessment.
Expertise of the site visit assessors

To get the best value from the site visits, the team members chosen to attend needed to be skilled and knowledgeable in the various elements of the fines reform. They also needed to be familiar with IT system software and the specific technical and business requirements that DJCS needed. This would help them effectively assess the suitability of the systems they observed.

DJCS did not put together a team with all of the right skills and knowledge needed to confirm the vendors could meet its requirements. The site visit attendees included three DJCS staff and the IT advisor. DJCS's staff were:

  • the executive director of IMES
  • the program director for the fines reform
  • a systems monitoring manager.

Project staff we interviewed suggested to us that during the initial stages of the project there was a lack of technical ability and project directing experience. One staff member in a key role advised us that they told their recruiting manager that they also did not have experience in leading an IT implementation project when they were recruited.

DJCS replaced the program director who attended the site visits in mid-2016. This change followed the December 2015 gateway 2 and 3 report, which recommended ‘consideration be given to the appointment of a skilled and experienced IT program director to lead the project through the current and future phases’.

Ultimately, the limited skillset and knowledge of the site visit attendees reduced the value of the international site visits in clarifying if a select tender process was appropriate.

The briefings and the evaluation reports do not indicate the extent to which the shortlisted vendors' systems' functionality aligned with the new legislation. Instead, DJCS's brief on the visits focused on how they would meet probity requirements, despite DJCS's probity advisor not attending the visits and the main aim of the tour being to assess the vendors and their products.

The IT advisor's market confirmation report contained information about the activities completed as part of the site visits. It indicates that the site visit team met with one of the successful vendor's prior customers while in London but did not contact two other London boroughs that had previously used the vendor's products. The team also cancelled a scheduled meeting with another customer due to it being 'logistically infeasible'.

The market confirmation report does not indicate that the team sought or were given detailed demonstrations of all of the components of the product that the chosen vendor was offering. This included the vendor's new debtor management module, which was an important component in relation to DJCS's needs. If the team had been given access to a testing environment for the vendor's product, they might have observed the gaps between its functions and the needs of the Victorian fines system.

These factors contributed to DJCS's lack of appropriate diligence in assuring that it was procuring a suitable product. They also suggest that the assessors were not adequately capable in the technical aspects required to make meaningful observations of the offered products.

Observations of the chosen vendor

At the time that DJCS’s site visit team conducted its observations, its chosen vendor's COTS system was reportedly in place in the London boroughs of Haringey and Harrow. These jurisdictions used the system to process traffic infringements, parking offences and issue permits, which involved hundreds of thousands of transactions per year. Other projects delivered by the chosen vendor were mostly for library and local council systems.

In contrast, the system that DJCS sought to procure would need to process approximately six million transactions per year, with those transactions being vastly more complex. DJCS failed to appreciate that the vendor's proposed system was untested in a like scope and scale. Simple inquiries, which DJCS could have completed in Melbourne, may have uncovered this information.

One of the VIEW project team members we interviewed described the vendor's base product as simplistic and specific to the needs of the councils that used it. They said the package was only being used in the UK for nine customers that were small councils, and only one of them was using it for fines. The team member came to learn that the product had not been modified for many years and had to be significantly tailored to suit the needs of the Victorian fines system because the base product only performed parts of the functionality that was required.

Figure 4E shows some of the differences between how the chosen vendor’s product had been used previously and the needs of the Victorian fines system.

FIGURE 4E: Comparison between the prior uses of the chosen vendor’s product and the characteristics of the Victorian fines system

FIGURE 4E: Comparison between the prior uses of the chosen vendor’s product and the characteristics of the Victorian fines system

Source: VAGO, based on DJCS and vendor procurement documentation.

Value for money

While DJCS considered value for money as a factor in its tender evaluation process, it was not a key focus during procurement. DJCS overwhelmingly based its procurement decisions on the vendors' ability to deliver the product on time. As previously discussed, one of the unsuccessful vendors submitted a proposal for delivering a system with a significantly lower price if DJCS delayed the launch date by approximately nine months. However, DJCS excluded this offer because it did not comply with the tender requirements. DJCS therefore ruled out any potential value for money that could be achieved with this option.

As mentioned, the select tender process only considered three vendors, which also limited DJCS's ability to explore if it could source better value for money options elsewhere in the market.

While the two finalist vendors’ resubmissions varied little in pricing over the long term, DJCS assessed the chosen vendor as better value for money in the short term.

Back to top

5. Lessons learnt

Conclusion

DJCS did not heed many of its own lessons from its previous failed attempt to develop a custom-built solution and repeated them in some cases.

Key causes for VIEW’s failings include that DJCS:

  • did not have a defined project management methodology
  • did not manage the risks that were inherent in concurrently implementing separate yet interdependent aspects of the fines reform
  • lost sight of the policy goal of debtor centricity
  • lacked contingency planning
  • failed to adequately manage conflicts of interest, increasing product customisation and the vendor’s performance
  • did not plan and undertake adequate testing of VIEW and launched it despite being unsure of its available functionality.

5.1 Lack of a clear project owner

DJCS did not appoint the director of Fines Victoria until November 2017, which was 32 months after the fines reform project commenced.

DJCS’s original business case for the fines reform planned for the director of Fines Victoria to be appointed in December 2016. By September 2016, it revised the director’s start date to September 2017. Three months later it pushed it back again to November 2017. There is no evidence that DJCS assessed or sought to mitigate the risk from this slippage in not appointing the director earlier.

As a result, the steering committee lacked an owner with the vision, mandate, capacity and accountability to drive the reform agenda. While the project had a deputy secretary as a sponsor to oversee the project, it lacked a person with day to day accountability for the work and the responsibility to be across the details.

5.2 Lack of proper project integration and planning

DJCS attempted to deliver VIEW concurrently with three other streams of work (transforming its business services, the fines policy reform and establishing Fines Victoria), which all needed to be in place by 31 December 2017.

There was no room for slippage in any stream of work or the flow-on effects would cause delays. DJCS did not properly plan and manage its different streams of work and their interdependencies and in doing so, failed to acknowledge and manage this significant project risk.

Establishing Fines Victoria

The Fines Reform Act 2014 established a new business unit—Fines Victoria—to sit within DJCS and manage all infringements.

Establishing Fines Victoria and its business model well before 1 January 2018 would have allowed the people who should have been defining VIEW’s requirements to focus on this rather than being divided between tasks. If established earlier, Fines Victoria could have:

  • defined the VIEW project’s benefits
  • been involved in VIEW’s pre-procurement and procurement to check that DJCS’s requirements would match the system it selected
  • tested that DJCS had delivered those requirements.

Not considering this option was a significant failing of DJCS's business case for the fines reform, the approval process and of the advisors to the project. Taking this approach would have reduced the risks and increased the likelihood of a successful solution.

Lack of project planning and management

DJCS also did not define or follow a project management methodology in undertaking the VIEW project. Experienced IT project experts would have been aware of contemporary IT project management tools and followed these structures.

For DJCS to have an IT solution in place by the date the legislation came into force was ambitious, but not impossible. However, our analysis of the detailed project implementation schedule, referred to as a road map, shows it was not realistic because the road map did not set out how DJCS would manage interdependencies if one component of the program faced issues, such as delays with the services contract and onboarding the director of Fines Victoria. To manage everything effectively, it needed a high degree of integration between the policies and business processes developed in non-system streams with the system implementation. There is no evidence of that occurring to the extent needed.

The proportion of time DJCS spent on procurement relative to implementation was also not balanced. For the business services transformation, the procurement took 14 months, which left only six months to onboard the service provider. Additionally, steering committee documents show that the procurement process for VIEW was nearly 12 months, but DJCS still planned to achieve the implementation in 15 months.

5.3 Loss of focus on VIEW’s intended benefits

DJCS did not have a comprehensive benefits management plan for VIEW and the fines reform until May 2019. This was 43 months after the government approved the business case, 32 months after a gateway review recommendation to implement one and 17 months after VIEW went live.

DJCS’s delay in creating and activating a benefits management plan is contrary to the government’s guidance and good project management standards. The lack of a plan to articulate how the public would benefit from the fines reform contributed to the project losing focus on the end user in VIEW’s design.

In August 2018, DTF's PAR stated there was ‘a considerable disconnect between the outcomes that are being achieved and the benefits that were intended to be achieved at the business level’. Having a benefit realisation plan early could have helped DJCS better focus its efforts and help drive its management of the project.

DJCS lost debtor centricity as a goal

The fines reform program and the VIEW business case named debtor centricity as a key outcome. To make fines easier for both the debtor to manage and understand and for DJCS to enforce, DJCS intended to bundle all a debtor’s outstanding fines into one account. VIEW needed to support and enable this goal.

However, DJCS lost sight of this goal in developing VIEW. DJCS only realised late in the process that VIEW did not have the capability to deliver debtor centricity as it originally intended. A range of issues led to this outcome:

  • Debtor centricity was not well defined. A benefits realisation plan would have helped DJCS to define debtor centricity and how it would translate the policy goal into VIEW.
  • DJCS re-used specifications for interfaces and other components from the previous project that did not have the debtor-centric aspiration of the VIEW project, which meant that these specifications did not meet VIEW's needs.
  • DJCS did not give debtor centricity prominence or weighting in its tender assessment, despite it being listed as a key system requirement.
  • DJCS and the vendor did not share an understanding of how to implement debtor centricity. In September 2018, the steering committee conceded that DJCS and the vendor’s interpretations of what a debtor-centric system included were not aligned. This was only clear once the vendor was on board and work was well underway.
  • DJCS discovered that the original policy goal for debtor centricity was somewhat unrealistic when it tried to make it a reality. Due to issues with the technical functionality required, it found that it was riskier to try to combine records for what appeared to be the same individual than to leave them separate. DJCS could not risk assigning debt to a person to whom it did not belong.
  • The struggle to get the basic system functionality in VIEW available for the go live date meant that debtor centricity was simply overlooked.

5.4 Lack of contingency planning

DJCS did not have any contingency plans in case it failed to deliver VIEW on time because it did not see this as an option. This was a serious and risky oversight by DJCS given the critical nature of managing and processing fines and the complexity of the project. By not developing a contingency plan, DJCS substantially increased the risk and impact of failing to deliver functionality by the go-live date.

DTF's gateway 2 and 3 report in December 2015 observed that:

‘… interviewees were emphatic in stating that all of the strategies applied and the activities undertaken during the market solicitation phase of the project are driven by what is seen as an aggressive, if not unachievable time imperative … [and] … interviewees saw no alternative to this approach and so no planning is currently being undertaken for a contingency’.

DJCS's budget calculated contingency funds at $3.8 million, approximately 15 per cent of the service work and only 8 per cent of the total budget of $46 million. At this stage, there was a known and fixed price for the system build, which made the costing more certain. However, the contingency allocation was low in the context of the history of a failed IT implementation, the newness of the legislation and service, and the number of stakeholders and interfaces. DJCS's business case also only planned for service funding up to the go-live date, with fixed-term staffing resources only contracted to that date and no funding for transition support services post go live.

Hypercare is the time immediately following a system go live where an elevated level of support is available to ensure the seamless adoption of a new system.

DJCS also agreed to a shortened hypercare period of two weeks. For a project of this size, even without the challenges, a six-week hypercare period is required with a tapering off if all is going well. Given the shortcuts taken up to go live, a two-week hypercare period was clearly inadequate.

DTF's gateway reviews did not directly address DJCS’s lack of a contingency plan. This was a failure of the gateway review process as DTF’s Gate 5 guidelines require a ‘check that there are feasible and tested business contingency, continuity and/or reversion arrangements'. Although listed as part of the scope in the Gate 5 review for this project, the lack of a contingency plan was not listed in the review's observations, raised as a risk or as a recommendation.

As DJCS became aware of the high degree of customisation of the vendor's product and that it did not have the time and capacity to undertake adequate system testing and staff training prior to go live, it still did not implement a contingency plan. For example, there was little preventing DJCS from making a last-minute offer to the existing service provider to continue its services. Instead, DJCS continued to rely on its belief that there would be enough functionality for the system to be viable, so it did not think this option was necessary.

A March 2019 review by an independent reviewer identified DJCS’s lack of a backup plan as a serious shortcoming and recommended the creation of a contingency plan as a critical remediation response. DJCS took up this recommendation as part of its remediation work in 2019. However, at this point in time, genuine opportunities to remediate the project’s issues were long since passed.

5.5 Failure to address contractor conflicts of interest

DJCS failed to manage a serious conflict of interest within the project. DJCS, like most government agencies, does not employ significant IT project management expertise in house. The steering committee subsequently relied heavily on external advice, particularly from the IT advisor, whose involvement created a conflict between their roles of being an advisor, implementor and project assurance reviewer.

The IT advisor's involvement in the project included:

  • undertaking the market scan and assessment
  • drafting VIEW’s system requirements
  • drafting the tender evaluation plan
  • undertaking tender briefings and fielding post-tender questions
  • attending international site visits to assess potential vendors
  • operating as VIEW’s project manager
  • seconding other staff to DJCS to work on the project
  • assessing and advising DJCS on the validity of the vendor's commercial claims
  • drafting the benefits realisation plan
  • advising DJCS on VIEW’s progress and readiness to go live
  • undertaking a post-implementation review.

As the IT advisor's involvement in the project increased, their ability to provide objective advice decreased. Further, the advisory firm's international office is the external auditor of the vendor. The advisory firm has said they disclosed this to DJCS. However, we were unable to fully verify this due to DJCS's poor record keeping.

In August 2017, when the VIEW project’s manager was on leave, DJCS asked the IT advisor to act in the role.

In December 2017, DTF's gateway review highlighted the lack of independence arising from the IT advisor being overly involved in the VIEW project and that the increasing involvement of the IT advisor diluted their ability to provide truly independent advice. It recommended that DJCS ‛consider sourcing new independent advice’. DJCS continued working with the same IT advisor.

When the project manager left in late February 2018, DJCS again appointed the IT advisor to act as project manager until July 2018.

Even as a temporary appointment, this was problematic. It effectively combined the roles of delivery and assurance, which undermined the latter. Both DJCS and the IT advisor have a responsibility to avoid conflicts of interest and would have been aware that the appointment diminished the credibility of the advisor’s assurance.

In February 2018, soon after the gateway review raised concerns over the IT advisor, DJCS sought and received an exemption from the state purchase contract rules to make it easier to engage the IT advisor on another role in the project. The deviation allowed DJCS to seek only one quotation from the IT advisor's firm and avoid getting three quotations from the market. DJCS cited time constraints, the IT advisor’s knowledge of VIEW and existing relationships with the vendor as reasons for seeking to retain them. However, DJCS did not acknowledge that those same factors contributed to the IT advisor’s lack of independence.

DJCS continued to rely on the IT advisor, who performed the post-implementation reviews in January and May 2018, as well as the June 2018 assessment of the vendor’s commercial claims.

DJCS made the IT advisor sign statements when hired, which said there were no conflicts of interest. Despite understanding the importance of independence, DJCS and the IT advisor disregarded this.

There is no indication that the IT advisor deliberately ignored and failed to communicate vendor issues. However, their involvement in choosing the vendor and implementing the project meant they did not have an objective view of the project’s performance, which violated the principles of good governance and project assurance.

The steering committee failed to recognise or address the IT advisor’s conflict of interest, and without adequate in-house IT project management expertise, was unable to check the quality of the IT advisor’s work and question their advice. The addition of the independent IT expert on the steering committee in 2016 did not help address this.

The IT advisor’s reporting to the steering committee was not an objective, evidence based assessment of VIEW’s functionality and generally mirrored reporting by the vendor. The IT advisor’s reporting included no independent testing of the vendor’s work. DJCS heavily relied on the advisor, did not test the quality of their reporting or require them to test the vendor’s output, so it did not realise it was flawed.

Despite the IT advisor consistently reporting to the steering committee prior to go live that the vast majority of functionality was working, the advisor’s May 2018 report stated that high levels of functionality had not been delivered and that:

  • there had been an underestimation of the complexity of fines correspondence, the interconnectedness of VIEW’s functions and issues with developing VIEW's reporting functionality
  • some of these issues could have been anticipated in 2017 before go live
  • efforts to mitigate the effects of these impacts on key stakeholders had failed.

The fact that the IT advisor failed to recognise and highlight these deficiencies prior to go live indicates that they did not do enough to independently interrogate VIEW’s readiness and DJCS did not identify or address this issue.

5.6 Failure to manage increasing customisation of the technology solution

As DJCS did not fully understand its business requirements for VIEW and the fines reform and was strongly predisposed to the idea of a COTS solution, it selected a technology solution that could not meet its needs. As a result, the vendor had to undertake significant customisation to provide the required functionality. Senior project team members told us that the level of customisation to VIEW may be as high as 70 per cent. This negates the perceived cost and time benefits of a COTS system and invalidates the premise on which the procurement and earlier options analysis were based. Essentially, VIEW is a customised build, not a COTS product. Figure 5A explains this issue further.

DJCS was late to acknowledge that it needed to significantly customise the vendor’s base product and manage the associated risk. For example:

  • six months into the project implementation, the vendor was already delaying software delivery milestones. It is not clear that the steering committee or the project team understood the root cause of the issues or tried to address them
  • in May 2017, DJCS closed off the customisation risk in its IMES reform program risk register, saying there was limited opportunity to customise the system. DJCS did not understand or plan for customisation and was not managing the risk it posed even until the point it closed out the register item
  • the steering committee and the vendor only recognised and acknowledged the change from a COTS to a customised system in October 2017, two months before go live. This left the vendor little time to adjust its development work. It also demonstrates DJCS's lack of oversight of and insight into the product it was purchasing
  • on 13 October 2017, members of the steering committee accepted that the vendor’s entire core product had been re-engineered. They did not reopen the matter on the risk register to address the increased risk.

By not identifying the risks associated with customising VIEW early in the project, the steering committee missed opportunities to manage those risks, re-calibrate project plans and keep the project on track. DJCS did not adjust or reduce its requirements, manage stakeholder expectations, or make significant changes to its business processes. If it had, it could have minimised the customisation and potentially achieved a quicker implementation. Limited customisation would mean that more complex features would not have been part of the core product and would need to be completed separately.

DJCS’s failure to manage this risk resulted in a range of consequences, including:

  • reactive and incremental resourcing as the vendor did not have staff with the required expertise to complete the customisation readily available
  • failure to meet software delivery milestones despite the vendor putting in over 30 000 added days of effort
  • more testing required than planned, and compressed time for this testing due to milestone slippage
  • significant pressure in the final stages of the project due to compressed development and testing time
  • a sizeable number of software defects
  • limited ability to upgrade the product in the future because due to time constraints, the vendor 'hard-coded' the software rather than implementing configurable options. This has many implications, including that DJCS is unlikely to be able to share development costs with other purchasers of the vendor's product or to take advantage of developments funded by other customers.

Figure 5A outlines some of the key differences between COTS products and customised software development using a house-building analogy.

FIGURE 5A: House-building analogy

IT systems experts often compare software development and the difference between COTS and customised software to building a house. Both types of projects are designed with the final product in mind. Specifications and methodology are developed to suit the specific project build.
Implementing software is complex and requires detailed specifications. COTS products can be compared to purchasing a house off the plan. The main structures and layout are predetermined and there are usually limited options for alterations and customisation. In both cases, a pre-existing model can be a quicker and cheaper option, provided the offered model is able to meet the purchaser’s needs. These needs could be the number of rooms or specific functions.
Both house builds and software development projects can benefit from involving architects. In software development, enterprise architecture provides a blueprint to manage current and future infrastructure and applications. It usually consists of a high-level map or plan of information assets, including the physical hardware. Even when implementing a COTS product, enterprise architecture could provide value in determining functionality needs and how to meet them.
Determining if an existing product meets purchasers’ needs is key because making changes can be difficult and costly, sometimes more so than when building from scratch. The less notice given for the changes, the harder it can become. Making last-minute changes to system functionality is often a lot harder and more costly than if they were planned.
DJCS undermined the potential time and cost benefits of choosing a COTS product by allowing its functionality to become too customised. It did not seek to accommodate the existing functionality of the base product by adjusting its own processes. Instead, it added to the system’s requirements and made ongoing change requests. VIEW was no longer an ‘off-the-plan’ build.

Source: VAGO.

5.7 Poor contract management

The main purpose of UAT is to check software against the business requirements. This validation is carried out by end users who are familiar with the business requirements. It should take place before the software goes live.

DJCS’s project manager released funds to the vendor before it had passed full user acceptance testing (UAT), which was poor contract management and a lapse in project governance.

The contract between the vendor and DJCS specifies software-related payments were to be based on UAT, yet DJCS made some payments soon after software delivery, which was well before scheduled testing. For example, the second software drop had a due date of 26 April 2017, but UAT was scheduled for November 2017. The steering committee’s finance reports indicate that it made the payment for this component soon after delivery in April 2017.

Staff we interviewed indicated that by go live, DJCS had released the vast majority of the project’s funding. A list of payments to the vendor shows that by December 2017, DJCS had paid over $38.34 million (or 83 per cent) of the $46 million budgeted for the system build. However, as DJCS later realised, the level of functionality delivered was substantially less than it expected. Releasing payments to the vendor before testing left DJCS little recourse when defects later emerged. It also resulted in DJCS having reduced leverage in its negotiation to settle the vendor’s claims about the work it conducted in addition to the contracted scope.

Contract variations

DJCS and the vendor did not achieve the revised timelines they introduced in their contract variations, partly because DJCS had not addressed the underlying causes of the original delays. DJCS and the vendor entered into two contract variations—Deed 1 and Deed 2. Each revision was entered into after DJCS and the vendor realised they would not deliver the required functionality within the set timelines. The Attorney General executed Deed 1 in November 2017 and Deed 2 in August 2018.

When DJCS and the vendor entered Deed 2, DJCS also agreed to settle a compensation claim that the vendor had lodged, which alleged DJCS had:

  • increased the scope of work—the vendor had to undertake work that was not part of the original contract
  • made multiple change requests to the system’s specifications
  • not clarified the complex requirements that the vendor was expected to deliver on
  • provided inadequate specifications that required constant reworking.

The timeline revisions under Deed 1 and Deed 2 were inadequate because DJCS underestimated the risks and root causes that had led to the delays. Thus, the revised timelines were unrealistic from the outset.

Because DJCS …

The variations meant …

DJCS responded by ...

Relied heavily on external expertise, it did not question the soundness of technical changes

Transitioning from one software release at a time to many releases. This introduced the risk that new releases would make the previous releases unstable, and the potential need for regression testing (a process to check that the recent program or code change has not adversely affected the existing features)

Not managing this risk 

Had poor oversight over the full fines reform program, it did not control the downstream impact of delays

By March 2017 (six months into the project’s implementation) software delivery milestones were being pushed out by two months

Allowing the vendor to add more resources (at an extra cost that DJCS paid through a commercial settlement) and deferring some functionality until late

By July 2017, the vendor was reporting a gap between the time it had and the time it needed to meet deadlines of about 1 800 development days. This was despite adding 31 more developers. This equates to needing an additional 28 developers (on top of the 31) to make the deadline achievable

Deeds 1 and 2 are clearer on DJCS’s change process and requirements than the original contract. DJCS began to accept that VIEW required far more time and effort than it had envisaged. Collectively, the deeds included a revised estimate of 55 000 days of effort, which is over 300 per cent more than the original estimate of 15 000 days. This would still turn out to be insufficient and VIEW is still not complete.

Managing vendor performance

Senior DJCS staff and steering committee members, including the DTF representative we interviewed, believe that the vendor was out of its depth in developing the complex and customised system that DJCS required. An independent March 2019 review also raised concerns over the vendor’s ability to deliver based on its performance.

However, the vendor’s performance relied in part on the information that DJCS provided to it. The inaccurate system requirements that DJCS provided to the vendor (outlined in Section 4.1) made it difficult for it to ensure it had the technical expertise and staff to deliver what was required. Custom system development requires a different skill mix than COTS implementation.

The early inaccurate assessment of the match between the vendor’s system and DJCS’s requirements had significant and lasting impacts. In addition to this, as interviewees conceded, change requests were poorly documented and this added to DJCS's difficulty holding the vendor accountable and managing the contract.

DJCS maintains that based on its ongoing dealings with the vendor, it is clear that the vendor was always aware its base product would require significant customisation to meet VIEW’s needs. However, due to poor documentation of requirements and change requests, DJCS reduced its leverage to defend its position in its dispute with the vendor.

System requirement changes

A BPRD is a formal document that specifies the needs and expectations of an organisation. It communicates to the technology service provider what the solution needs to do to satisfy the customer’s business needs.

Because DJCS provided poorly detailed and misleading requirements to the vendor at the outset, it subsequently needed to make significant clarifications and changes as the system developed. DJCS made over 1 500 change requests to the system, which increased the workload and time required to complete it.

We found that DJCS adjusted the requirements after it had signed the contract with the vendor and development was underway. This included new process documents that DJCS provided to the vendor late in the process. It provided some key function requirements to the developer on 30 December 2017, which was one day before the go-live date. For example:

  • in November 2017, DJCS provided 12 business process requirement documents (BPRD)
  • in December 2017, it provided a further five BPRDs
  • DJCS did not supply the BPRD specifying payments management, which is a key system function, until 30 December 2017.

Figure 5B shows examples of some of the significant changes to requirements that the vendor claims DJCS requested after development was underway.

FIGURE 5B: DJCS’s changes to VIEW’s requirements as alleged by the vendor

Change type Description of changes made
Warrant changes DJCS requested fundamental changes and additional complexity in the system’s functional requirements for warrants through BPRDs, the warrant matrix, workshops, and familiarisation sessions.
Reporting changes DJCS requested to increase the number of reports required for implementation from 80 to over 180 midway through the implementation phase.
Interface changes DJCS requested numerous changes to the number of systems VIEW needed to link to and how data moved between them.
Additional testing There was originally no UAT concept within the system delivery and support agreement (the contract between DJCS and the vendor to implement VIEW). DJCS later introduced UAT to the test management approach.
BPRD scope development The example BPRDs provided in the initial stages did not represent the final BPRDs. The final BPRDs were far more complex.

Source: VAGO, based on documentation from the vendor.

DJCS supplied 5 600 VIEW requirements to the vendor in two batches. It provided the first batch of 2 600 requirements to all of the vendors as part of the request for tender in January 2016. It provided the second batch of an additional 3 000 requirements to the chosen vendor in late 2016 after the contract had been signed. DJCS stated that this second batch of requirements represented clarifications to the original requirements, which it developed to assist the vendor's understanding. However, the decision to provide the requirements in batches meant that the vendor was not given the full picture of DJCS's needs for VIEW before it signed the contract. The vendor also had less time to ensure it had the proper resources for the job.

The high volume of requirements led to a dispute between the vendor and DJCS. The parties did not litigate the distinctions between which requirements were original, which were new, and which were clarifications or changes. The dispute put significant strain on the working relationship between the parties. DJCS and the vendor reached http://Testing VIEWa settlement in order to continue work on the VIEW project.

5.8 Inadequate testing of VIEW

The steering committee did not ensure that sufficient UAT was conducted on VIEW prior to it going live. The project team and steering committee knew that the testing was inadequate leading up to the go-live date, yet no one addressed it. This meant that when DJCS advised the Attorney-General that VIEW should go live as planned, it did not fully understand what functionality was available. DJCS should have addressed these risks, extended testing timelines and clearly outlined the risks to the Attorney General before going live.

Subsequently, DJCS was surprised by VIEW's lack of functionality at launch. DJCS estimated in a later review that VIEW had 5 per cent functionality when it launched. This contrasts sharply with the expected 90 per cent functionality that the vendor said would be available at launch.

The delays in testing also hindered DJCS's ability to identify system limitations and train staff on effective workarounds. This likely contributed to administrative errors in fines processing and poor customer experiences. DJCS said that in the months following go live, approximately 400 people incorrectly lost their driver licences, and penalty reminder notices and other correspondence were sent to people who had previously been identified as deceased.

Including UAT

DJCS's initial contract with the vendor had a poorly defined UAT concept. While the contract mentioned the state doing testing, this was not specified as UAT. DJCS and the vendor’s failure to directly include UAT suggests that they either did not understand its importance or did not understand that the level of customisation to the COTS product would warrant it. DJCS had to define UAT at a later stage and at an added cost. DJCS should have recognised and mitigated the risk earlier in the project. The significant customisation made to the vendor’s base product meant testing was critical.

Testing plan

The testing plan that the vendor prepared follows commonly accepted phases of testing. However, there is little evidence to show that it followed the details of its own plan. For example, we could not see that it met the entry criteria before commencing testing. The entry criteria were that there would be zero priority 1 (P1 critical) and priority 2 (P2 high) defects. Failure to follow the plan shows weakness in DJCS’s management of its contract with the vendor.

The extent of testing required increased and time available for testing decreased due to:

  • the need for a lot of new code to accommodate the high degree of customisation, which is inherently prone to more defects
  • the increase from 'several dozen' system interfaces in DJCS's requirements to 62
  • the increase in the number of reporting functions from 80 to 180
  • delays to other reform components, which meant that DJCS staff that would ultimately use the product and therefore should have been involved in the testing, had not yet commenced, including business services transformation project and Fines Victoria staff.

Under the business case, system testing was meant to start in July 2017 and run for three months. Instead, it began in November 2017 and ran for six weeks. Rather than extend the testing time frames, DJCS ran testing phases concurrently. Although there is normally some time overlap for phases of testing, running them concurrently is highly problematic because defects from each level of testing will impact the others. It is particularly problematic for UAT, as users do not have a stable solution to test.

Figure 5C shows the planned versus actual dates for system testing.

FIGURE 5C: Planned versus actual system testing activity dates

  Start date Duration
Business case Actual Variance Business case Actual Variance
System test Jul 2017 14 Nov 2017 +4 months 4 months 1.5 months −2.5 months
Interface test Jul 2017 Sept 2017 +2 months 4 months 3 months −1 month
UAT Oct 2017 24 Nov 17 +7 weeks 6 weeks 4 weeks −2 weeks
Time after UAT before go live (training) Dec 2017 31 Dec 2017 +1 month 1 month 0 months −1 month
Acceptance test report Nov 2017 31 Dec 2017 +1 month - - -

Source: VAGO.

Discussing risks to testing

DJCS had a project manager working with the vendor on testing, defects and resolving them. They attended steering committee meetings as required to share status updates and answer questions. The last report on defects before go live clearly outlined where there were defects and where testing had not been completed or was limited by ongoing development work. Figure 5D shows the number and priority ratings of defects that were reported around go live.

The project manager said they outlined the risks associated with the lack of testing to the steering committee, but the steering committee advised that ‘not going live was not an option’. After highlighting these risks again, they said they were told ‘not to talk about risks anymore’ and were told privately they were ‘too negative’ for continuing to call out the risks. It is concerning that there was a culture of suppressing open discussion of risks. Not openly addressing and managing these risks led to VIEW launching with a high number of defects.

Insufficient time to train operators

The lack of adequate testing meant there was little time to train those using VIEW before go live. As a result, service staff could not process fines efficiently, which contributed to people facing delays with payment plans and reviews and led to people having their driver licences wrongly suspended because of difficulties nominating the actual driver responsible for speeding.

This challenge was compounded by new staff who would be the main users of the system starting at the same time the system went live.

Managing software defects

VIEW still had a large number of defects post go live. As DJCS and the vendor completed further testing following go live, the number of software defects rose from 410 to 460, with most rated critical and high priority.

Figure 5D shows the difference between the number and priority ratings of defects before and after VIEW launched, as assessed in January 2018. Of the additional 50 defects detected within 11 days of go live, 41 (82 per cent) were high or critical. The cause of this increase in defects was the lack of adequate testing to identify them earlier. Another contributing factor could have been that the testers were not representative of the people who would use the system.

FIGURE 5D: Number and priority rating of software defects detected before and after VIEW went live

FIGURE 5D: Number and priority rating of software defects detected before and after VIEW went live

Source: VAGO, based on information from DJCS.

Back to top

Appendix A. Submissions and comments

We have consulted with DJCS, Department of Premier and Cabinet, DTF and the Victorian Public Sector Commission, and we considered their views when reaching our audit conclusions. As required by the Audit Act 1994, we gave a draft copy of this report, or relevant extracts, to those agencies and asked for their submissions and comments. 

Responsibility for the accuracy, fairness and balance of those comments rests solely with the agency head.

Response provided by the Secretary, DJCS

DJCS response letter page 1

DJCS response letter page 2

DJCS response letter page 3

DJCS response letter page 4

DJCS response letter page 5

Response provided by the Secretary, Department of Premier and Cabinet

DPC response letter

DPC action plan

Response provided by the Secretary, DTF

DTF response letter

DTF action plan

Response provided by the Victorian Public Sector Commissioner, Victorian Public Sector Commission

VPSC response letter

VPSC action plan

Back to top

Appendix B. Acronyms and abbreviations

Acronyms  
BPRD business process requirement document
COTS commercial off the shelf
DJCS Department of Justice and Community Safety
DTF Department of Treasury and Finance
FES Fines and Enforcement Services
FRAB Fines Reform Advisory Board
HVHR high value high risk
IMES Infringement Management and Enforcement Services
IT information technology
PAR project assurance review
SaaS software as a service
SRO senior responsible officer
UAT user acceptance testing
VAGO Victorian Auditor-General’s Office
VIEW Victorian Infringements Enforcement Warrant
VIMS Victorian Infringement Management System
Abbreviations  
COVID-19 coronavirus

Back to top

Appendix C. Scope of this audit

Who we audited What we assessed What the audit cost
  • DJCS
  • DTF
We assessed:
  • DJCS’s process for analysing system options and its procurement process for the new fines system
  • DJCS’s governance for setting up and overseeing VIEW’s implementation and if it is achieving the expected benefits
  • if DTF’s HVHR gateway review process was applied to VIEW as required.
The cost of this audit was $845 000.

Our methods


As part of the audit we:

  • held formal interviews with current and former staff from DJCS involved in the procurement and implementation of VIEW and Fines Victoria
  • held formal interviews with the vendor and independent advisors on the project
  • reviewed the business case, gateway reports, market scan and procurement documentation, ministerial briefings, meeting records and internal reviews
  • reviewed costs incurred by DJCS in implementing VIEW and subsequently in responding to and remedying the system’s deficiencies.

We conducted our audit in accordance with the Audit Act 1994 and ASAE 3500 Performance Engagements. We complied with the independence and other relevant ethical requirements related to assurance engagements.

We also presented a copy of the report to the Department of Premier and Cabinet, the Victorian Public Sector Commission and DTF.

Back to top