Slashdot Mirror
Army's Huge SAP Project 'At High Risk'
itwbennett writes "The Army's $2.4 billion SAP project is delayed, over budget, and, once implemented may not even meet its original objectives, according to a recent auditors' report. For its part, the Army is less concerned with the auditors' findings about the project that will manage a $140 billion annual budget and serve nearly 80,000 users once it is complete: 'The Army believes the risks identified in this report are manageable and do not materially impact the [project's] cost and schedule,' said an official with the Assistant Secretary of the Army (Acquisition, Logistics, and Technology)."
When you go with SAP.
The only people who will get something out of SAP are the consultants who get paid to "fix" it.
"Forget the engineers." -Carly Fiorina, briber of MIT Technology Review.
Why that isn't cancelled, but Webbs telescope is? Ah, its thats the Army....
RIP US space program
Because:
a) They always employ people with the right connections instead of the right competence
b) Because the consultants they hire know the real money comes from doing it wrong? Why make an effort to deliver on schedule and under budget when you can take your time over it and earn twice as much money in the process?
You might think I'm joking but I've sat in some of the meetings. When I arrived I was under the delusion that I was there to do some work but I was completely wrong, we were only there to kill time before going off to a nice little French restaurant somebody had discovered. My bad.
No sig today...
the real money comes from doing it wrong
The longer I stay in the software industry the more this fact depresses me.
http://michaelsmith.id.au
In Australia a State Government used a ridiculously expensive "off the shelf" SAP payroll solution that turned into a complete disaster. A year later and staff still aren't being paid properly. Lots of finger pointing between IBM, SAP and Corptech who is the State Government's IT corporation. They paid $40M for software that didn't work, and still doesn't work.
Take that number in. $40M. Ridiculously overpriced even if it did work, but this doesn't even do that. Payroll isn't rocket science. A few competent programmers locked away for 6 months could do better. Far too much money is thrown at so-called 'enterprise software'.
http://www.itnews.com.au/News/218348,ibm-under-fire-for-qld-health-bungle.aspx
http://www.arnnet.com.au/article/351650/ibm_says_queensland_health_sap_failure_its_fault/
http://www.zdnet.com.au/qld-health-sap-woes-lead-to-cash-advances-339302381.htm
http://www.goldcoast.com.au/article/2010/05/07/215335_gold-coast-news.html
http://www.theaustralian.com.au/australian-it/qld-health-pays-hefty-price-for-sick-payroll-system/story-e6frgakx-1225813063057
http://www.computerworld.com.au/article/351608/updated_qld_govt_blames_ibm_health_payroll_bungle/
They probably hired a big, fat consulting company like Accenture to implement SAP for them, who's in it to get even fatter by putting as many unqualified warm bodies on a contract as possible, rather than hiring a someone who will actually run it like a project and get out... someone who is actually concerned about the customer's best interests. One would hope that the Army would know better.
c) They still believe in Waterfall development methodology. They also believe in "fixed-price" contracts. It's the change requests that kill you. The consultants gladly build what you asked for. Then when you realize that you really didn't know what you wanted, they have you.
1. It's written in fucking COBOL
2. It's the vilest user interface I've ever seen. I have no idea how anyone could come up with something that bad.
3. C. O. B. O. L.
It fails just as often in the private sector, the difference being that there, the client usually goes bankrupt before you hear about it.
My company recently switched to SAP... it more than doubled the time it takes us to do anything. that software is garbage, yet people keep buying into it. they have great salespeople.
Now the US army is switching to it? The military will shut down. We joke that the Germans (it is german software) are getting the world back for beating them in WWII.
You can't understand how bad this software is until you actually see it.
- The user interface is the worst of any software product I've ever used, and I'm not exaggerating.
- The user documentation is even worse
- I'm told the developer documentation is worser still, esp. if you don't speak German.
- COBOL is so fucking awesome.
- It costs a leg, an arm, your first born and your left nuts. Oh and your soul.
Because it's not their money, and they're not spending it upon themselves.
Milton Friedman identified 4 types of spending:
I've done work on government projects and seen money thrown at projects that made absolutely no sense at all. Projects that just fizzled out or never got implemented. It doesn't happen in the competitive private sector. People do a project because it makes/saves money, and then make it work.
Gosh, that's going to be the most insightful comment. The only thing I can do is ammend it a bit.
Currently, as least in Europe, every high priced contract needs to be tendered in the open. This however means that you need to know beforehand what you want. So basically they bring in the consultants at an early stage to create the business case. Then they tender the thing (after a Q&A of the possible participants). And of course price will be a big decider for who wins the tender, so each and every participant will have little flexibility in their business plan. And then they will over charge when change requests are made.
The problem with this kind of business practice is that while the practice of tendering to the lowest bidder is - in itself - a good thing, it completely breaks down if you want to do any kind of modern software development techniques. The use cases are already cast in stone when the contract is done (and even much of the design will have to be present for the participants to create any kind of realistic price). IMHO, they would be better off doing it inhouse, with a company that supplies the software people and software development practices, and an external consultancy firm that specializes in project management (and gets payed for getting that part right).
"The Army's $2.4 billion SAP project is delayed, over budget, and, once implemented may not even meet its original objectives"
Surely "The Army's $2.4 billion SAP project is a SAP project" would have been sufficient, guys. ;)
Yes it does. You just don't get to hear about it either because it's confidential or because private sector waste isn't a good story.
I have worked on many projects in the private sector and heard about plenty more where the IT director has believed what a salesman told them and ended up with an absolute disaster. What you say might be true for SMBs but big organisations are not too different to the public sector.
The SAP R/3 kernel is written in C. The application layer is written in ABAP and can be extended in ABAP or Java. So, the the claim with COBOL is BS.
Haha, SAP.... :-/
(mod me +5 insightful, I used SAP for years and promise that I deserve it based on the short but very insightful comment/review above)
Huge projects usually fail because they are deadline-oriented. From there everything goes down the drain because every bump on the road will cause the project managers to either :
1) compromise on the quality of the implementation, which leads to resistance from the people in charge of maintenance because they feel that problems are offloaded to their department. This actually initiates a downward spiral in quality and collaboration areas.
2) compromise on the number of features that are delivered, which leads to resistance from the project owner and will usually cause significant side effects as the impact of missing components is underevaluated.
Both alternatives lead to more bumps in the road, and the cycle starts again.
A deadline-oriented project also places consultants in a perfect position to do whatever they want, which is usually either repeating a solution that worked in another organization (without really knowing if this is a good fit in the new one) or taking the opportunity to learn something new that they can put on their resume. Whenever someone complains they have this magic wand called "deadline" which they can use to make all the restrictions (such as design patterns or IT best practices) go away.
When the deadline becomes a goal instead of a guideline, and when an organization is ready to let consultants call the shots instead of placing them in a controlled sandbox where they can bring value without creating chaos, then the project is doomed.
lucm, indeed.
I spent 30+ years in IT doing administrative programming. I saw this sort of thing happen constantly. Almost all the users I ever dealt with were of the "How do I know what I want until I see what I get" persuasion. So we gave them what we thought they needed and told them to live with it. They did. If you tried to force users to define their needs as completely as possible, you'd never get out of the requirements-definition phase of a project. Never. Users have neither time nor inclination to define their needs that thoroughly. And user management assuredly isn't competent to do it, at least not at any place I ever worked. And as far as SAP goes, it's a steaming dung heap (one way to assure your continued employment is to understand your employer's SAP implementation thoroughly, because no outsider will ever be able to do so).
Well, I'm a consultant working primarily for government, and I can honestly say that those aren't the reasons why these projects fail.
Corruption in hiring is surprisingly rare in western countries, and usually involves only a small subset of the people on a large project. I've heard it's a serious problem in developing countries, but I've only seen it a few times here, and and I've only ever seen it lead to a project failure when the project team was only a handful of people.
You'd be surprised about the work ethic of consultants.
For some consulting organizations, there's so much work that they prefer to have their consultants finish projects quickly so that they can go on to other projects and hence satisfy all of their customers, not just some of them. Not turning up at all is a surefire way of losing a customer to your competition, which can go from nonexistent to serious in very little time if they suddenly start landing big projects.
More commonly, consulting is only a part of what a company does. Large vendors like SAP sell licenses, support contracts, and consulting separately. If one branch of the company starts annoying the customers (too expensive, slow, incompetent, etc...) then this drags down the results of other branches too, and then their executives become very angry and complain directly to the CEO. God help the consultant working for an organization that makes most of their profit from licenses if the fuck up a sales deal!
Lastly, consulting firms tend to hire better-than-average people, and those tend to be high achievers and motivated professionals. Delivering projects on time and on budget looks good on a CV, and can lead to even more lucrative positions.
I've seen enough projects that I've figured out that government contracts go over budget or time for several inter-related reasons:
- Ridiculous levels of risk aversion -- if there's no bonus or profit to be had, then no risk is worth it. This leads to some very stupid decisions, over-engineering, etc...
- Management overhead -- big bureaucracies ignore the cost of management overhead, because the only way to reduce it is to fire a bunch of managers, but management makes hiring and firing decisions! Almost nobody would ever fire themselves. Instead, managers rationalize the need for management. There's no arguing with people about useless processes, when the existence of that process, useful or not, keeps them employed.
- Conservative approach to IT -- a big project is hard enough, but when you also have to deal with decades old software and sometimes even hardware, the difficulty becomes astronomical. In quite recent times, I've come across all sorts of fun things in the core infrastructure of large organizations. For example, OS/2 is still in use. Novell NetWare refuses to die. I've seen Windows 95 as a server in a data center just recently. I did a lot of work on an enterprise DOS application just a couple of years ago. It's not just systems, but processes to. Why change anything, just because the software is completely different, and the hardware is six orders of magnitude bigger or faster?
So imagine being the consultant hired to rip up and replace 10s of millions of lines of code across hundreds of undocumented systems, most of which should have been cleansed with purifying fire decades ago, but you're not allowed to. Instead, you have to sit patiently through a never ending series of pointless meetings that serve only to prevent any bureaucrat from ever having to make a decision, or take any blame for anything.
There have been succesfull projects with waterfall methods. There have been a lot of succesfull projects with fixed price contracts: for the last 15 years I've never done business on any other basis (both as buyer and as supplier) - if you know what you are doing it's not a problem at all.
Even competence of the people involved isn't an issue. In a project that big, there's bound to be a lot of nitwits but the competent people can usually work around them.
No, what kills this thing is that even with the Gods of IT themselves on this project, once the scope exceeds a given size (you can measure that in the budget, anything over 100 million will never succeed) the amount of time needed to build and confirm that requirements have been met, exceeds the time before those requirements change. Also, the more people on the project, the larger the amount of overhead and internal communication.
Now, what agile development says is exactly what Fred Brooks says: more people on a project makes it later.
What they need to do is to cut down the scope to something manageable. They can waterfall or Scrum it to their hearts content then, but size the scope first.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
You really have no idea do you? Plenty of private sector projects fail too after many years of incompetence and it may shock you to know but governments hold companies to contracts, have clauses about non-delivery, incentives for early completion that sort of thing. Come back when you've actually worked somewhere large rather than talking utter bollocks.
My company runs SAP as its ERP system, and the project was only a little late -- but on budget and met its initial goals. We were migrating from Daly & Wolcott on an AS/400. Then again, we only have about 260 employees, and we did a fair amount of the work using our own people. We didn't just foist the whole thing off on consultants, as is most often the way.
As someone who writes integration code with ERP systems, I can say that for all the problems SAP has, it's not nearly as terrible as others. I've worked with CORRIDOR, BAAN, and Quantum Control MaxDB, and all of them are terrible, horrible monstrosities that barely work, are wildly oversold, have terrible user interfaces, are mostly undocumented or improperly documented, and are apparently designed to be as difficult to interact with as possible. Add to that stupid programming decisions (CORRIDOR uses materialized views for all DB work as opposed to stored procedures; Quantum Control loads DLLs by reading them into memory as data then jumping to their entry points, causing massive issues with DEP and weird crashes periodically) and it's amazing anyone buys these pieces of crap. By comparison, SAP is a thing of pure beauty, with its (usually) correct documentation, rock-solid stability, and actual supported interface points (RFC and IDOC).
The problem is that ERP systems all stink. SAP just happens to stink the least.
The Freelance Wizard