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?
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.
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...
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).
I have a lot of respect for the lads and ladies at the GDS. They're doing some sterling work.
Imagine, they could actually pay health care workers properly if they stopped hosing taxpayer money down the gigantic nepotism drain.
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.
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.
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.
You should read the post mortem on the Target Canada debacle to understand the pressures behind a huge software project.
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.
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.
How does one spend $1 billion on software and fail?
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.”
Actually I don't even know how SAP became so popular it's horrible
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...
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.
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.
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.
A similar thing happened when DHL acquired Airborne.
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"
Eventually, DHL terminated US domestic shipping
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.