Hacker News new | past | comments | ask | show | jobs | submit login
DHL Global Forwarding Failed on Software, and That’s Why It’s Being Sold Cheaply (flexport.com)
74 points by howrude on Feb 23, 2016 | hide | past | web | favorite | 43 comments



Slightly OT but the history of DHL co-founder Larry Hillblom[1] makes for some interesting reading.

[1]: https://en.wikipedia.org/wiki/Larry_Hillblom


Wow, you're not kidding. It didn't even stop when he died.


What a crazy life!


Thanks for sharing that!



Ryan Petersen here, author of this article. I should clarify one thing: I don't believe the rumored sales price of $4B. It's just too cheap. If any PE guys (or Google/Amazon/Alibaba people) out there is reading this and wants to back me in buying the business and giving it another go, I am game.


Pretty mind boggling. How does one spend $1 billion on software and fail? I guess this is a somewhat misleading accounting statement based around maintaining the existing software orgs of the merged companies, not building new software.

It makes me wonder though, with an unlimited budget and willingness to pay a lot, what could one achieve in one year? If you offered 200k base, 100k signing, and 1 mil bonus for completion of goals within 1 year, that should give you access to pretty much all the top tier programmers in the world. Hire 50 of those guys and you're only at 65 mil. Maybe you need a really incredible guy running it so you offer him a 30 mil bonus. Now you let those guys attack the problem and it's hard to imagine they couldn't fix things up at DHL within 1 year.

Any known examples of orgs trying this approach?


"How does one spend $1 billion on software and fail?"

Just look at most UK Government IT projects. They've got it down to a fine art, blowing billions and being left with nothing useful.

Several major international government consultancy firms got their break on supposed small UK Gov IT projects, and were able to keep billing $1,000's/hour for years (while delivering nothing useful) and became big IT consultancies in the process. The failure didn't harm them one little bit - it let them claim the have experience and that got them way more work.

IT project failure in large and complex organizations is practically guaranteed.

Now, if they did that small-ish team, paid well, it could well work. But your board is not going to approve some pizza munching, jolt cola drinking geeks as your wonder IT team. Don't worry what the team is really like, the consultants asked by the board to review them as part of the process will make sure they're described as the aforementioned pizza and cola weirdos. And recommend using the consultants team instead. Been there. Done that.


There's no board for UK government IT projects.

The process starts with lobbyists (from the likes of Fujitsu, CSC etc) offering fancy dinners, a few trips to the opera, family holiday in Barbados, and crucially a revolving door, behind which is a future lucrative senior position should they decide to engage the services of said company. Lucrative senior position will in part involve lobbying former government friends and colleagues.

And so the cycle continues...


NHS Connecting for Health literally was that board.

Also, never attribute to malice that which is adequately explained by stupidity -- or, in this case, incompetence. If you're telling yourself that the difference between billion-pound boondoggles and small, competent and motivated teams working to agile principles is a bit of low-level corruption (so lightweight that none of it could be discovered and prosecuted under the Bribery Act), you're looking in the wrong place (and you'll also struggle to explain how and why the Government Digital Service was set up, and why they're succeeding).


Yeah, you're right. I am generalising and cynically caricaturing; though a fair bit of that stuff does go on. The current system of self-regulation is sorely in need of reform and legislation, but those tasked with legislating are the ones who benefit from the current system.

I have a lot of respect for the lads and ladies at the GDS. They're doing some sterling work.


The NHS blew £10bn on one software project that never delivered and was scrapped. This is very normal in UK govt procurement. See also what we are spending on aircraft carriers with no planes.


Don't forget the ongoing costs. Nhs choices costs £3 per page-view from last year's figures. It's a largely static site.

Imagine, they could actually pay health care workers properly if they stopped hosing taxpayer money down the gigantic nepotism drain.


It's horribly slow and doesn't seem to work well at all neither. Hopefully the new NHS digital team will take over that entirely soon (http://nhsalpha.herokuapp.com/)


The sad thing is if you say this is evidence the NHS needs some reform, a load of freaks will appear screaming "save our NHS!!" Not even realizing they are just saving the profits of Accenture shareholders.


A better question is, "How do you spend $1 billion on software and succeed?" The fundamental problem isn't the quality of your developers, it's the fact that you have to coordinate multiple environments composed of mutually-irreconcilable workflow and processes, legacy systems never designed to talk to anything, and real-world problems that aren't amenable to solutions at scale. Big Bang projects are almost impossible to get off the launchpad in a single piece, so can we learn from the ones that actually make it to orbit? Or is there an inverse Tolstoy effect here -- every failed project is alike, but every successful project is successful in its own way?


Rumor has it that Halliburton spent almost $100mil ( or was it $900mil I forget) on trying to do an ERP upgrade so I'm not surprised at all.

It's not just about the money though, it's also about having the mandate to get shit done (and probably hurting a bunch of feelings/fiefdoms) along the way.

Keep in mind, there's not this one magical system that keeps things going that by getting a bunch of really smart guys will right itself.

Often times, it's a combination of COTS and custom software that has grown organically over the years.

So take for example, one of my previous projects, which was to spin up new IT for a PE spinoff. There were over 70 major applications to account for with tons of associated business processes, functionality etc. It was a massive undertaking but yes, it's doable.


How does one spend $1 billion on software and fail?

Epic failure creating sofware is common enough that there's a Wiki page commemorating it. https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_...

My own state managed to piss away around $200 million just on a website to sign people up for health care. It's hard to believe something that insane, but Oracle was involved so perhaps it's plausible.


Well NHS in UK spend £10bn(thats about $14 billion) in failed IT. http://www.theguardian.com/society/2013/sep/18/nhs-records-s...


The industry studies I've seen have shown that, in addition to most enterprise projects failibg, project failure is positively correlated with project size.

My experience in enterprise software suggests that the way many large enterprises -- private and public -- wrap more layers of review, bureaucracy, and big up front design on projects the more money is involved (specifically intended as a risk management technique) is a big contributing factor to this.

So is the idea of a big software project. Almost without exceptional, large enterprise "software" projects really need to be conceived as business process reengineering efforts, where changes to automation are one of means of implementing the reengineering.


Sounds like you haven't read Mythical Man Month. There are a ton of issues that dictate the success or failure of an IT project and money isn't one of them.

You should read the post mortem on the Target Canada debacle to understand the pressures behind a huge software project.


I don't know anything about shipping IT systems but my guess is that it's not just a software in the cloud. You have a lot of hardware involved. Sorting facilities, delivery guys, etc. If that environment is heterogeneous and you need to replace all the hardware or adapt to lots of different hardware, I can easily see how things can go wrong.

The other thing is how can a business person tell the difference between a star programmer and some random mediocre coder? It's not like if it is a profession with reliable minimum standards. It's a bit like psychanalysts, anyone can declare himself a developer.


These are details. The main problem with large projects is that they become complex political games across umpteen divisions. It's futile to think about how you should deliver X functionality if nobody can tell you exactly what this functionality is, who will be forced to use it for what task, and whether these conditions will change in 3 months. The result is an orgy of meetings and committees producing directives that are all over the place, and where interested parties can easily sneak in their own pork and/or agenda.

Any IT project above £100,000 should have a clear line of command, the power to overrule any workflow or operational convention with very little discussion, and freedom to engage in localized feedback cycles without formalized oversight. Pick small and tightly-knit IT/dev teams that can guerrilla their way through the organization with blessed impunity, and just let them loose.


By thinking your problem is a software problem when it's not.


  How does one spend $1 billion on software and fail?
For example : http://calleam.com/WTPF/?p=3474


Found my favorite near the bottom: "Design by committee."


I always find myself wondering this as well. The only way I can think of is they decide to hire thousands of mediocre employees and churn the money away with rewrites and busywork.


>> I don't believe the rumored sales price of $4B. It's just too cheap

Interesting. I have no expertise in this space, but someone that does says $5B is a generous valuation, and $4B is correct.

"“It is a rich valuation, but is not prohibitive, particularly given that Japanese companies tend to overpay in mergers and acquisitions. At $5bn, DHL Global Forwarding, which has paltry margins, would be valued at about 0.33x sales and 15x EBIT, assuming sales and EBIT have not changed much year-on-year...A $4bn price tag would make even more sense, based on fundamentals.”[1]

[1]http://theloadstar.co.uk/deutsche-post-ponders-sale-dhl-glob...


Thanks for the article, but as a person that knows next to nothing about the logistics, I'd like to read more about the topic. For example, what kind/types of software company such as DHL uses? What are the biggest problems (I guess complexity is high on the list) in improving its software side? What could be some creative solutions to this 'software fail'?


SAP what else

http://www.pcworld.com/article/3010156/sap-dont-blame-us-for...

Actually I don't even know how SAP became so popular it's horrible


Oracle ERP is just as bad. At $job-2 they spend $500m and 5 years to get zero modules of Oracle Retail installed and eventually decided to just continue on with the mainframe legacy systems.

The latest Software Engineering Radio has an excellent discussion of the topic of large scale IT failure aka black swans: http://www.se-radio.net/2016/02/se-radio-epislode-250-jurgen...


LMAO. A similar situation happened at Stanford about 10 years ago ($150-200MM usd frittered away).

Projects ran by vampiric consultants whom bill hourly -> "big deliverable never" -> ~ gigabuck$.

Smart tech buyers don't get locked into unbounded contracts without milestones and don't let drivers of project management to an external party. Instead, focus on customer need driven, fixed contracts and incremental milestones are generally a better approach.

SAP/Oracle/PeopleSoft/BMC/etc. implementations often tend to fall into these traps when they're poorly managed and/or when the buyers are suckers. Business unit owners and IT managers with backbones are needed to hold vendors accountable to deliver on promises, milestones and deadlines, or payment is not disbursed.


My guess is the "no CTO got sacked for choosing SAP" marketing. Business people are rightly scared of large IT projects, and SAP is the safe, german way.

The other thing is that SAP does not (or at least did not) offer consulting services / configuring their software, they just sell the software, unlike most of their competitors. What it means is that all of the IT consultants will tend to push clients to choose SAP vs a competitor because it means more business for themselves. That's from my experience 10y ago, I don't know if it's still the case.


Support contracts and beautiful sales people, same as Accenture


Most enterprise projects fail, either in terms of budget, time or functionality.

Pretty much any telephone billing system is late or shelved, for example.

In this case, you have a shipping conglomerate with divisions that can't talk to each other.


Have more confidence to comment on your real account, it's good to see people making sweeping generalizations based upon personal experience! People who can present and back opinions are valuable. None of this anonymous cog-in-wheel stuff. Incidentally, if you think they're all late or shelved, and have some experience with them, I'd consider combining forces to develop and market a new one. I have prior multilingual call-center development experience (hardware, SIP, fax, in+outbound, reporting, customer ID from caller ID, etc.) and extensive finance experience.


"The company then spent another $1 billion in a failed attempt to build a unified IT backbone to tie together the acquisitions. Late last year the company killed the project, known as New Forwarding Environment, deciding to stick with its legacy systems."

A similar thing happened when DHL acquired Airborne.

http://www.informationweek.com/dhl-airborne-didnt-take-the-e...

After the smoke cleared, Infosys had the most understanding of the systems (along with solution support) but domain knowledge and software expertise slipped away. If I had to describe the atmosphere, it could be summed up by Nicholas Carr's article "IT doesn't matter"

https://hbr.org/2003/05/it-doesnt-matter

Eventually, DHL terminated US domestic shipping

http://www.bloomberg.com/news/articles/2011-04-14/dhl-reboot...


The company then spent another $1 billion in a failed attempt to build a unified IT backbone to tie together the acquisitions. Late last year the company killed the project, known as New Forwarding Environment, deciding to stick with its legacy systems. In an object lesson on the risks entailed in roll-up strategies dependent on massive IT integrations, Deutsche Post now appears ready to cut its losses and sell the division at a huge discount.

Consider that DHL Global Forwarding generated more than $16.5 billion in revenue in 2014. At a purchase price of $4 billion, that’s a sales multiple of just 0.24X. Expeditors, its strongest rival in the U.S. market, currently trades at 1.3X revenue. If DHL Global Forwarding could be priced at Expeditors’ revenue multiple, its price would exceed $21 billion.

Worth noting that Expeditors (my former employer) has the complete opposite strategy compared to DHL, in both business (organic growth with no major acquisitions) and IT (homegrown systems with no major COTS purchases).

Basically, in the build vs. buy debate, Expeditors has been on the side of "build" while DHL has been on the side of "buy." This is far from the only difference between the two companies, but I think it's been a major factor in their fates.


Seems like a really blatant ad to me. The author's best guess on why DHL failed happens to be exactly what the author's key selling point is.


All journalism is content marketing.


I always found DHL Global Forwarding a pleasure to work with, because it was so personal. People answer your calls. I'm sure that's not great for profits or high volume customers.


Was Accenture[1] somehow involved in this backbone?

[1]: https://www.accenture.com/t20150523T030128__w__/us-en/_acnme...


integration architecture for old big systems is so difficult people make a very good living if they´re any good at this. Software architects in that field can make up to five times as much as a regular senior developer. I guess this article shows why.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: