>Publicly funded broadcaster makes same mistake most large private enterprises make in more or less the same way.
Actually large private enterprises don't usually make this kind of mistake. This is a typical big government project. Software development is hard. Building large, complex, poorly defined software systems is hard.
//EDIT
I should clarify that. I don't think a private enterprise would engage in a project that would have it build an internal system, at that scale ($100 million), having so little impact on it's primary revenue driver, over so many years!
Big enterprises fail with big software, that's a fact. But they wouldn't fail in this specific way. This is a quintessential big government software project failure.
"Actually large private enterprises don't usually make this kind of mistake."
Really? You sure about that? Because hard numbers are hard to come by, but I'm pretty sure they do with some frequency. It's notoriously common for large consultancies not working for the government to have the same outcome too.
It's possible private enterprise makes this mistake at a different rate than the government, but I'd despair of trying to prove that claim, or even give it a solid definition. In general large software initiatives seem to fail, regardless of whose bright idea they are.
There's nothing special about private enterprises that makes them immune to risk. As others have said, many IT projects fail [1]. In the private sector this is just seen as a business risk, but when a public sector project fails then its "wasting taxpayers money".
For some reason the Economist article doesn't mention that the project was originally awarded to Siemens and Deloitte [2], but technical failures and cost overruns by these private companies caused the BBC to bring the project in-house. It could be argued that the BBC lacked the capability to deliver the project on its own, but thats also a mistake found in the private sector.
There's something special about private enterprises making them reconsider their approaches, though - the fact that they lose their own money (which is often combined with having a smaller pool of money to begin with). Few enterprises can spend $150M and fewer will keep spending upon signs of things not working out.
As to private contractors doing a poor job when paid with taxpayer money - makes some sense, as long as said money keeps flowing. In a different setting the flow would stop more quickly.
This is untrue of large private enterprises, which are quite capable of throwing good money after bad, engaging in wishful thinking, and all the rest of it. As another commenter pointed out, the difference with the public sector may rather be that private failures can be more easily hidden.
I did one stint at a BigCo, during which they blew over $100M on a "platform of the future" project on which all their disparate software products were going to be developed going forward. It was obviously never going to work, yet they kept funding it and kept pushing it on all their software teams. Even though this was a massive failure, it was never announced as such or even explicitly canceled. It just crawled off to die alone somewhere. Official rhetoric was that the project had succeeded, and the executive who had championed it was promoted to run the entire software division of the company.
Edit: so I think the salient difference here is not private vs. public, but large vs. small.
In what sense is it "their own money"? The programmers at a private enterprise are not doing anything with "their own money" besides collecting a salary. The same detachment from the outcome that happens in government work can happen in businesses, and it does all the time.
The people at the top of a business software product might be stockholders, so they could have some risk. The people at the top of a government project also understand that it will be their photo in the media along with the public outrage. And both understand that the consequences - whether public anger or a dip in the stock price - are temporary and will go away in a few weeks.
According to barb.co.uk, BBC 1 (the flagship TV channel) had some 45M viewers over a recent week. We could consider other channels, radio stations and the website, but that's already well over half the UK population. By cost per customer, that's more than an order of magnitude better than your newspaper example.
This is not actually true, I am not aware of much info on CMS roll outs, but large CRM and ERP software projects at private enterprises fail all the time.
This is very common, I think perhaps the hacker news crowd probably have more experience with real software behemoths like google, facebook, microsoft and/or scrappy smaller start ups. Perhaps in those realms this doesnt occur because software delivery is their bottom line. In run of the mill fortune 500 companies major software projects fail commonly, and CRM and ERP projects fail even more frequently and have price tags in the 10s of millions, and when they fail the company has no choice but to roll out a new one
"Levi’s is bucking the industry-wide trend by going ahead with ERP now. 'It’s expensive, high risk and requires a lot of cultural change, and unless you have a really compelling reason to do them you don’t [during a downturn],' says Paula Rosenblum, an AMR Research analyst."
Your edit: ..having so little impact on it's primary revenue driver..
Sorry, you are still wrong. The BBC is specifically in the business of video content and their failed system was a video content management system. You can not get any more core to a business than that! This is a quintessential big software project failure I do not see how it being in government has anything to do with it or how you have made any kind of case for that belief.
> Actually large private enterprises don't usually make this kind of mistake.
I would say "Actually large private enterprises don't usually [admit to making] this kind of mistake." I swear the ERP and document management are the two areas where every enterprise tries to "standardize across organizational units" and fails badly[1].
I have come to believe that this type of software is hard because it imposes rules foreign to the entity on it and doesn't value a companies existing workflow[2], or it requires thousands of developer hours to adapt.
1) oh, they keep using the new system, but their customers feel it
2) often a very successful workflow for the entity and its customers since the entity can now afford a multi-million dollar software package
ERPs are a great example. but I don't necessarily agree with your view that a large enterprise's existing workflow is superior. My take:
Most large enterprises have workflows which could be vastly improved by automation of ANY kind, even one that is imposed by a minimally customized ERP. ERP implementations are most successful, on both an ROI front as well as success in implementation, when they are brought in and the existing workflow, at a high level, is redesigned to fit the tool. Why?
The other path is chaos, because you are essentially asking people whose jobs revolve around doing things manually to "build their own replacement." A simple way of putting it is getting the assembly-line workers to have input on a new, highly automated assemblyline. They don't want the robots to do their jobs for them. Instead they will all insist on the value of their interaction in the process, and the robots will simply be tasked with helping them do their job instead of simply replacing them.
When ERPs succeed, they lead to lots of admin people getting laid off or reassigned. These are the same people that have to be consulted if you want to customize them for a company's existing workflow. They fight tooth and nail to keep everything the same as it was.
Good points, and my thoughts exactly when I left university with a business degree.
My take now:
The workflows of large enterprises are not really well understood at all. With lean management and how management careers work, even the lowest management levels has only a vague idea what is actually happening in their departments.
Designing even a tiny system for a small number of users requires a lot of time and a lot of love. People do many more things that they could ever put into words. The new system breaks many things in ways that are difficult to describe. The users are defenseless because they are up against huge projects with a lot of momentum and are not prepared to communicate those kinds of problems.
Uhm, so let's hope that your ERPs are actually succeeding.
I'm not sure if you are assuming that I'm a naive guy who is fresh out of university or not. In case you are, I am not. I worked for a small company (I was the 6th employee, and it grew to 150 people) whose largest project was an ERP implementation for an extremely large enterprise which I shall not name, but you would immediately know them. I was not involved on the project directly, but was frequently pulled in to advise those who were. Said organization went down a rabbit-hole trying to map out all of their workflows so that we could customize the ERP for their needs. What a nightmare. I am now witnessing a successful ERP implementation in another large organization. The first priority is to minimize customization.
General Electric is a model of how to implement an ERP. They followed the minimal customization model, and forced their workers to change their workflows to take advantage of the tool. The key is to identify all of the data an org needs, and make it accessible. If your developers don't have an excellent metadata analysis/storage tool (homemade or bought) they are screwed.
I was not assuming you were naive or fresh out of university. I was assuming however you came from the consultant's perspective.
I am sure that you must recognize, that when people complain about ERP implementations not fitting, they refer to implementations that you describe as "model"?
I come from the other end of the spectrum, making my first steps building business-process relevant tools while employed in various functions. What really shaped me was having carefully discussed the requirements, building it as specified, then being called because "it is not working", and realizing then and there what the actual business logic was, and how deep it was buried and how dysfunctional it all would have been had I insisted that I had implemented as specified.
I'd say (to the consultant profession in general), grab the proverbial pistol and flashlight (http://en.wikipedia.org/wiki/Tunnel_rat), and go down the rabbit hole, because that's the only way the job can be done right.
> General Electric is a model of how to implement an ERP. They followed the minimal customization model, and forced their workers to change their workflows to take advantage of the tool.
Yep, that's the model, but I contend it is a pretty poor model for everyone but the ERP vendor. It is basically saying the ERP or CRM vendor has a better grasp of a companies business process than the company. I have seen companies adopt a ERP and use its process, then anger customers because of the change. Since they follow a new path, many times it is IT telling the rest of the business how to run things[1] and much of the institutional knowledge is thrown out.
1) something as simple as what's on the invoice or payment voucher can have huge affects on customer experience in some industries.
There are a lot of numbers tossed around without a lot of hard data backing them up, but it's generally accepted that over half of all large software projects 'fail' at both private companies and government institutions.
> Actually large private enterprises don't usually make this kind of mistake. This is a typical big government project.
Your last two points contradict your first two. There's nothing unique about a government's ability to make terrible decisions. I'd say one difference is that private enterprises typically go under if the mistake is big enough, and they have no great interest in telling the public about their mistakes.
"I just don't think a large enterprise would engage in an internal $100 million project to build a CMS."
Isn't this a circular argument? If a company doesn't want to build a system in-house then its only other option is to contract another company to build it. At some point, someone has to build the system.
>Actually large private enterprises don't usually make this kind of mistake.
Are you new or something? Do you know how many projects I've been brought in to rescue? Do you know how many times my advice to "Stop throwing good money after bad" has been ignored for one reason or another?
Big enterprises fail in exactly this kind of way. All. The. Time.
Like many of the comments below I don't agree with this statement.
I have been at several mid to large sized private companies and have watched at least 4 $30mm+ projects go up in smoke over the years. Fortunately I have not been involved in any of them directly but I got a front row seat. Surprisingly more then half didn't result in extensive turnover of the key parties involved.
Actually large private enterprises don't usually make this kind of mistake. This is a typical big government project. Software development is hard. Building large, complex, poorly defined software systems is hard.
//EDIT
I should clarify that. I don't think a private enterprise would engage in a project that would have it build an internal system, at that scale ($100 million), having so little impact on it's primary revenue driver, over so many years!
Big enterprises fail with big software, that's a fact. But they wouldn't fail in this specific way. This is a quintessential big government software project failure.