Accreditation risk

A recent case involved a software firm suing the Government for setting accreditation criteria that allegedly put it out of business.

In Integrated Education Software Limited v Attorney General [2012] NZHC 837. The plaintiff company, IES, had provided school management software since the 1980s. By the 2000s, it was one of a number of software providers to New Zealand schools.

Around this time, the Ministry of Education decided to implement interoperability standards for school management software. As the judgment notes:

The overall market was … very fragmented. There were 37 software vendors providing software to the compulsory education market. Most were small. Some were one-man back shed operations. The school software market had grown organically over the decade since 1989 and, although it was almost entirely state-funded, there were no uniform standards or other controls in place to ensure product quality.

… there was also concern within MoE about the variable quality of software packages and after-purchase support. Lack of technical expertise at school management level meant school leaders were often unable to make good choices. Ultimately it was felt that this represented a risk to government in terms of wasted expenditure where software was not up to spec or the vendor company failed.

So the MoE decided to set an accreditation model whereby software packages that met certain requirements would be accredited. A financial incentive would be put in place for schools that used an accredited package.

After some refinement and teething problems with the accreditation criteria, testing was carried in 2005. Seven vendors received accreditation, but IES did not. Users of IES’s software began to migrate to other, accredited vendors.

As a result, IES claimed that the accreditation process had damaged its business:

Although MoE argues that IES was in fact losing clients before the second accreditation round, there can be no doubt that IES’ failure to achieve accreditation did have a significant impact on that company’s fortunes. This occurred at two levels. First, it made it harder for IES to retain existing clients in the face of monetary incentives to change and MoE’s aggressive change campaign. Second, and for the same reasons, it made it more difficult for IES to attract new clients from the pool of 300 schools hunting for a new provider.

IES brought claims against the Government for:

  • Negligence, on the basis that the accreditation process was misconceived and poorly carried out; and
  • Bias / breach of natural justice (s 27 Bill of Rights Act).

Both of these claims (and another) were rejected.

On the negligence claim, the Court found that MoE’s adoption of an accreditation model was a policy matter, in which Courts are traditionally reluctant to intervene:

 The means by which the government is to fund the provision of SMS services to schools so as to ensure proper interoperability and appropriate standards in an era of widespread computer usage is a policy matter… These are questions for officials and politicians not Judges.

It also found that the MoE had no duty of care to IES in formulating and carrying out the accreditation process (it is worth noting that the Court suggested that the “proper footing” for a claim of this nature would have been misfeasance in public office), and considered that key facts were not made out.

On the bias claim, IES pointed to evidence it said showed that the MoE’s accreditation criteria favoured another vendor. The Court disagreed, saying there was no evidence to support an allegation of bias.

Lessons

The case provides an example of regulatory risk for IT vendors, and confirms that the Government has a broad (though not unlimited) ambit to implement standards, accreditation regimes and other policies without judicial interference. It is logical and sensible for a Government agency such as MoE to implement baseline standards (e.g. interoperability requirements) for state-funded schools, and accredit providers meeting the standard to allow schools to make an informed choice. It is unfortunate that IES, for whatever reason, could not or did not get accredited in time (in 2005).

The case does not explain why IES could not alter its software to meet accreditation. Software development is often an expensive and time-consuming process, and many vendors would face financial or resource constraints to significantly update what may be a “legacy” package to meet new requirements (which they may consider to be flawed or inapplicable).

But if IES had been able to update its software before or during the accreditation process (over a period of some months and years), presumably it could have reduced it alleged losses. Whether this could have been alleviated by a different contracting model or business model is unknown.