News: 1600072206

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Infor pays UK construction retailer Travis Perkins £4.2m settlement following cancelled upgrade of 'Sellotape and elastic bands' ERP system

(2020/09/14)


Global ERP slinger Infor has paid UK hardware and construction retailer Travis Perkins £4.2m in settlement for a four-year failed ERP project that cost £108m.

In its half-year [1]interim results [PDF] published last week, the retailer said the "gain of £4.2m is the result of the full and final settlement of claims in relation to the cancelled replacement of the Group's merchant ERP system".

The settlement relates to an earlier statement from Travis Perkins' [2]full-year 2019 results [PDF], published in March 2020, which said: "Following the change in approach to the replacement of the Group's merchant ERP system announced in July 2019, the Group terminated its relationship with Infor… in October 2019 and formally set out its damages claim."

The full-year results also detailed a £108m impairment relating to the halting of the ERP replacement programme. The decision to end the programme leaves the £7bn-revenue retailer, a household name in the UK, running its main enterprise systems in green-screen environments dating back to the 1980s, sources close to the implementation told The Register .

In fact, Travis Perkins admitted as much when then CEO John Carter told the audience of Infor's New York conference in 2016 that its systems were "being held together by Sellotape and elastic bands".

With great fanfare, Carter and then Infor president Stephan Scholl shared the stage to discuss the 24,000-user implementation of the CloudSuite version of Infor's core M3 ERP product in a deal expected to be worth $200m to the software vendor over 15 years.

According to [3]reports , Scholl declared: "It's the largest cloud ERP transaction in this game."

But sources speaking to The Register said it was not long before the project started to go wrong. A central problem was a lack of scrutiny of the design phase, which did not include functional specifications for interfaces, database schemas and security schemas. With barely any input from the IT department, business leaders in charge of the project said these aspects could be decided later during the construction phase.

"It was just an absolute mess," one source said.

By 2018, Travis Perkins was no longer able to hide problems with the project. [4]Half-year results [PDF], published in June 2019, said the "ERP replacement programme in December 2018 as this programme has continued to face significant challenges".

The trading statement continued: "As a result, the Group is considering whether to implement the various elements of an ERP system as separate items, after modernising the Group's core IT architecture. A revised approach may incorporate components from the existing project, however under accounting standards the Directors have concluded that the existing assets of £111m should be written off."

But by the end of 2019 it was all over. As well as ending the relationship with Infor, the full-year results detail the Group's "possible obligations under the relevant contracts, which include break clauses limiting the Group's maximum possible contractual exposure to circa £65m".

"In the view of Directors, it is probable that the Group will be able to successfully resolve this matter without making any payments to the software provider," the results said. "Accordingly, no provision has been made in respect of these contracts. The Directors expect this matter to resolve in the next 48 months."

It continued to describe "improvements required to core IT and digital platforms to enable the businesses to perform, and to adapt their propositions as customer demands change".

Travis Perkins has not responded to The Register 's requests for comment.

Infor's revenue was [5]$3.2bn as of 2019 [PDF]. [6]It was bought by the privately owned Koch Industries in February 2020 in a deal thought to be worth $11bn. It has also declined the opportunity to comment on its relationship with Travis Perkins. ®

Get our [7]Tech Resources



[1] https://www.travisperkinsplc.co.uk/sites/travis-perkins/files/interim-results-2020.pdf

[2] https://www.travisperkinsplc.co.uk/sites/travis-perkins/files/FY19-press-release.pdf

[3] https://www.cloudpro.co.uk/leadership/6147/infor-scores-biggest-ever-win-with-travis-perkins-cloud-deal

[4] https://www.travisperkinsplc.co.uk/sites/travis-perkins/files/HY19-Press-Release-final.pdf

[5] https://webassets.infor.com/resources/Investors/Financial-Overview_October-2019.pdf

[6] https://www.theregister.com/2020/02/04/infor_koch_buyout/

[7] https://whitepapers.theregister.com/

Barely any input from the IT department

Warm Braw

That rather suggests things might have gone badly awry even before the contract was awarded.

Re: Barely any input from the IT department

beaker_72

Hard to believe that they would have signed off on that size of project without speaking to the techs, or that Infor wouldn't have flagged doing so as a massive risk.

I'm sure that the in-house tech folk and Infor would be happy to point the finger at the business being the problem though. I suspect the reality is a little more nuanced.

Re: Barely any input from the IT department

Anonymous Coward

Same shit happens in our company.

Gob-shite company: "We need this shit doing within the next two months".

Gob-shite us: "Ermm, that isn't much time, but we could possibly make it, if we work a few hours extra (for free) and make some shortcuts (less/no unit tests, hard-coding stuff that should be configurable, etc.)"

Gob-shite us have found something that would delay us a few days because the gob-shite company.

Gob-shite company: "What the fuck? A fucking delay? How fucking dare you?!?! You should fucking thank us you have jobs, ingrateful fucking tossers".

Tis only our fault, should have delayed the first projects that had unrealistic timelines, but I imagine that's what they wanted. Our team was the fucking runt of the litter and it always felt like it.

Agile?

Anonymous Coward

> these aspects could be decided later during the construction phase

But ... but ... this is Agile and we all know that Agile can't go wrong?!?

Re: Agile?

SecretSonOfHG

It can't go wrong as long as you embrace the Agile principles because the definition of "not wrong" is embedded in these principles (wheter that's good or bad is another discussion) And nowhere in those principles says that Agile is adequate for fixed cost/fixed schedule projects that have no scope defined down to the precise wording and layout of documents and UI and precise specs of business processes. Which is something I haven't seen in any project in the last 35 years.

I don't want to sound smug, but I cannot think of any methodology that accepts changes in cost and scope without assuming schedule or budget changes that can possibly work.

"did not include functional specifications"

Pascal Monett

Sorry, but there's your problem.

No project should be started without knowing where you want to end up. I don't care if you use Agile or Waterfall, you still have to know what the required functionality is and a company that cannot state its needs deserves to fail.

This is obviously a bunch of high-level "managers" who have never been confronted with the daily grind and think that IT is a magical process that just happens.

Well no, it doesn't "just happen". It needs thought, planning and employee adoption, and you obviously got none of those.

Re: "did not include functional specifications"

SecretSonOfHG

"No project should be started without knowing where you want to end up"

This is the first hurdle, nobody will accept such a simple goal as "to replace existing IT systems without changing any business process in any way, shape or form" after commiting a good chunk of money to the project. Because that means likely that the old business processes were designed to work around the old system limitations and thus are very inefficient and cumbersome. So nobody wants that, instead they want to end up in "somewhere better", without even starting to specifiy that somewhere and that better.

When in fact, they should start aiming for getting rid of the old system, no matter how clumsy or idiotic processes they need to keep. And the incrementally refactor whatever they want to improve.

But it never happens like that. Sadly

To ordinary folks, conversion is not always automatic. It's something
that may or may not require explicit assistance. See Billy Graham. :-)
-- Larry Wall in <199710141738.KAA22289@wall.org>