Barely any input from the IT department
That rather suggests things might have gone badly awry even before the contract was awarded.
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 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 …
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.
I had a manager splurge 500K on a new hosted solution that would end all of our problems without talking to us. When everything was signed they (bare in mind this is a support manager in IT) spoke to the support staff explaining what the solution was, he didn't even name the product.
"Won't work" came the squeak from the back of the room, "printers won't interface with it properly on remote sites"
I still remember him going pale as it clicked - we didn't direct print as we have specialised printers.
They spent months trying to come up with a solution, ended up binning the whole project and paying penalties to get out of it.
If only they'd spent 10 minutes talking to staff on the ground.
I have been on projects where:
IT was over-ruled on the choice of software for a $150 million project that subsequently because the system just couldn't deliver what was promised and replaced less than two years later. Not even over ruled by the corporate heads who knew the business, but by the investment group that owned the corporation.
Operation negotiated and signed a systems contract with a vendor and only made IT aware when implementation was to begin. That one failed too, oddly enough, in that it didn't do what operations needed.
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.
I discovered something in forensic science that carries over perfectly into IT and no doubt many other specialities as well:
The world is divided into two types of people, those who don't bother to speak with their specialists because they don't want to waste their time as they don't expect to get anything useful from them and those who consult their specialists from the beginning because that way they get better results. Oddly enough, both find that experience justifies their position.
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.
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.
"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
> So nobody wants that, instead they want to end up in "somewhere better", without even starting to specifiy that somewhere and that better.
The answer is a couple of lines up. First you identify the system limitations that are being worked around in laborious ways, THEN you work out how you're prefer thing to be done, THEN you go back and see if what you've come up with actually makes sense or if there are other things elsewhere which are causing the entire broken chain you just devised a fix for that could be fixed and make the whole thing redundant.
The road I live on has a traffic problem (massive congestion in peak hours, dangerous speeding in off hours). The residents are clamouring for more pedestrian crossings "to make it safer for people to cross the road". Anyone pointing out that a bypass road was built 40 years ago to get traffic OFF the road, but the intersections around it were never revised to encourage traffic onto that/off the old road, and that the old road is still setup to encourage through traffic gets you looked at like you have a second head. They only look at the issues that are happening right in front of them instead of zooming out a little.
"The answer is a couple of lines up. First you identify the system limitations that are being worked around in laborious ways, THEN you work out how you're prefer thing to be done, THEN you go back and see if what you've come up with actually makes sense or if there are other things elsewhere which are causing the entire broken chain you just devised a fix for that could be fixed and make the whole thing redundant."
What they should really do is build the solution anew. Send people in and see what the users & business actually need to do and build a solution to achieve that, removing any and all dependencies and kludges used to get the old system doing things it was never designed to do and ensure the new system does everything properly for today's demands and has some extensibility so future demands can be accommodated without to many future kludges.
many long lived institutions are running stuff from the 90's and before, why is it that more modern stuff can't cope with changing demands?
"First you identify the system limitations that are being worked around in laborious ways, THEN you work out how you're prefer thing to be done, THEN you go back and see if what you've come up with actually makes sense or if there are other things elsewhere which are causing the entire broken chain you just devised a fix for that could be fixed and make the whole thing redundant."
THAT used to be the job of the Systems Analyst. But that's no longer hip and cool.
The classic problem is that you are failing to identify what "somewhere better" means. And it can mean different, even contradictory terms, depending on the business unit. In your example, "somewhere better" for pedestrians means having more crossing points, road traffic be damned. For motorists means a different thing than for pedestrians. What you have in front of you is not a system design problem or an architecture problem, but a plain old politics problem. Same in business. And, let me add, those political battles hardly have a clear winner, and nobody wants to wait for the battle to be settled before starting to build the new system, much more if they can take advantage of some tactical feature or side effect of the new system.
Complex problems have complex solutions, and often what the "best" solution (compromise between the parties) is not found after a few iterations. If you think you can get it right first time, you're doomed even before you start. Except if you're dealing with satellite/space shuttle levels of safety
"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."
Alternatively it could mean that years have been spent fitting the system round the quirks of the way the business is run but in which case why change the systems? Because shiny? Because persuasive salesman? Because big manager wanting to prove how important they are?
>No project should be started without knowing where you want to end up.
Spent a fraught 8 weeks working on producing the PRINCE2 PID for a client project that was supposed to be well beyond that stage. (normally its a couple of days work as you can cut-and-paste from other documentation.)
Neither the PM nor the customer lead could understand why I was having so many problems until it (slowly) dawned on them that simply deploying 3000 laptops (*) to the field workforce wasn't going to deliver any business benefit, furthermore, the field engineers weren't employees but contractors working for third-party companies and thus the business benefits and efficiency savings previously identified would largely accrue to the third-party companies and not the customer's own company; additionally, the changes would require contractual ways of working changes that would also involve union representatives - as the IT lead, I didn't have the authority to conduct such negotiations...
Managed to deliver and get board sign-off for the (enlarged) budget, although it nearly cost my job...
(*) Yes laptops with just MS Office installed, no consideration as to how these laptops would be used and maintained out-in-the-field and how they would reliably communicate with corporate (SAP) systems.
Infor were responsible for our System 21 AS400 ERP for many years.
When I joined the company and learned my way around the AS400 it was very clear that it was "sellotape and elestic bands". We essentially had two ERP systems, an ancient one and a half install of its replacement. Both systems had been left talking to each other via triggers. It worked fine till it didnt, then you'd have to jump through hoops trying to convince Infor that they had to fix it as they were being paid monthly to do just that. Most of the time we were sent links to knowledge base articles telling us how to do Infors job for them, links that were not relevant because we were in a no mans land of an old ERP half upgraded to another now old ERP replacement.
Once the system went down due to a UPS shutdown. The system didn't come back up at all, on a bank holiday where I was the only IT support all day. Could I call them? Everything was dead. NO reports had been generated, the delivery note printers wernt printing and lorries were stacking up at all the sites phoning me asking why the printers arnt working and why the AS400 screen was blank. Infor had no clue why, even though they were experts on AS400 they had no clue. We spent a week having them manually triggering jobs on the AS400 just to have us get by, invoices, EDI, report generation all of which should have been automatic were now manual. Till our AS400 guru came back off holiday and discovered that the issue was the UPS shutdown program cleared the AS400's startup program value to have the AS400 start in a restricted state. So called AS400 experts like Infor, seeing a system that no longer starts correctly might have checked that the startup program was set.
Oh and there was the time where I had them on to fix something for a user. The guy killed the interactive subsystem. For anyone who dont know AS400, the interactive subsystem is basically a telnet server that allows ALL users access. If you kill it their screens literally go black and they are logged out with no access till its started again. Just what my boss needed, me coming into the cafeteria to pull him away from his lunch as the entire user base were locked out.
Infor also had all our custom source code, yes we had AS400 developers once and they created our own code to fix the system. When they all left Infor got the code and agreed that they would support it. Did they? Barely!
We eventually jumped ship.
I find it very hard to believe that Travis's business is so unusual that an off the shelf system could not be readily tweaked into usefulness.
A quick rummage around in some old B&Q/Homebase/whatever news items would probably reveal the providers of their IT solutions, who I have no doubt would love the opportunity to double their money on a tried and tested system, that requires perhaps 6 months of bespoke jiggery pokery.
Sure enough, everyone will need retraining to fit in with the new system, but that was always going to be the case.
The "funny" thing is that TP are/were in a group with other brands like Wickes etc who do ERP differently and better.
In my experience Infor are bloody horrendous though, presented with a "cake on a plate" - all business units within group had fully mapped processes, existing ERP that worked fine and could have been directly "ported", the only reason for change was ending of support and group HQ wanting a "harmonised" system, Infor took 3 years and then bottled it at 75% done...
My company has just replaced an ERP system. That system replaced the original one that ran on ICL Mainframes until someone realised that the ICL's wouldn't survive Y2k. The original ran on greenscreens.
The original system would still run runs around either of its two replacements if it was still with us :-(