Not Just Healthcare.gov: NASA Has 'Significant Problems' With $2.5B IT Contract 176
schwit1 writes "According to the Inspector General, NASA and HP Enterprise Services have encountered significant problems implementing the $2.5 billion Agency Consolidated End-User Services (ACES) contract, which provides desktops, laptops, computer equipment and end-user services such as help desk and data backup. Those problems include 'a failed effort to replace most NASA employees' computers within the first six months and low customer satisfaction,' the report states (PDF). It adds that NASA lacked the technical and cultural readiness for an agencywide IT delivery model and did not offer clear contract requirements, while HP failed to deliver on multiple promises."
I hate Dice.com (Score:1, Insightful)
We are not an audience (Score:1, Insightful)
I've got to say that the initial post on this topic perpetuates one of the paradigms that is sticking in the craws of Slashdot users. We are not an audience. We might be users, we might be members, we most certainly are contributors. But we are not an audience.
If you persist in thinking of us that way, then you're going to get it wrong. You serve an audience differently than you serve contributing members of a community. Most of the complaints hinge on that difference.
If we were an audience, we'd be coming here for the articles. Most of the complaints are about the comment system, how difficult it is to follow a conversation, how difficult it is leave a comment, etc. I come here, most of us come here, to read what my/our fellow slashdotters have to say. The value here is the community, and the most important contributors are other members, not the site or the editors.
If you don't get that straight, then you aren't going to "get" why we're upset, so there's no chance that you'll deliver us something that we can live with. And that community is going to vanish, leaving you with nothing of value.
You can take suggestions and maybe reduce the implosion, but unless you understand *why* we're upset, you're going to be heading in fundamentally the wrong direction.
BETA looks like any other news site (Score:2, Insightful)
Re:I also hate beta (Score:0, Insightful)
Dnot 4git 2 h8 BETA 2! b/c BETA sux baw1sax
Re:Typical.... (Score:5, Insightful)
I think you are asking for the wrong skills of someone in a management role of IT. There are people who can build a PC, install the OS and drivers yet not be able to code their way out of a paper bag. In fact trained monkeys can do that, and there are plenty of certified monkeys. I don't care if the manager can build a PC. I care if the manager knows the difference between hardware and software.
Has the manager of a development group ever written any software in his life?
Another massive fail is that they do not hire the brightest people. They also encourage a culture that repels the brightest people. Bureaucracy. Red tape. Dress codes. Discouraging and even punishing creativity. Encouraging brown nosing and politics. No wonder they can't build an application even with billion dollar budgets.
No amount of money can fix the problems I described. No amount. Give them ten times the budget, but don't change the real problems and the project will still fail. They don't get this. There are no signs that they ever will get this.
Imagine (Score:5, Insightful)
Imagine you're a NASA worker with a nice (albeit old) Macbook computer to do your work on.
Some schmuck walks up to you with a brand new hp laptop with Windows 8 on it to replace your Mac.
I fail to see the scenario where the NASA worker _shouldn't_ enthusiastically shun the "helper" from hp.
When the choice is between something nice and functioning and a crappy os on a crappy piece of hardware, the choice is easy.
The problem with these "one size fits all" contracts is that one size does not fit all situations ever.
If hp wants to make this contract successful they should be forced to offer multiple options through multiple vendors where they take a cut to manage the maintenance and configuration of any of the possible selected systems.
Re:Typical.... (Score:4, Insightful)
This is what happens when you under fund the IT budget
Throwing $2.5 billion at "desktops, laptops, computer equipment and end-user services such as help desk and data backup" doesnt sound like underfunding IT to me.
Re:Typical.... (Score:3, Insightful)
Welcome to Management One on One
Re:I don't understand (Score:4, Insightful)
Feedback for Timothy (Score:4, Insightful)
I was reading this review of Slashdot Beta made last October, which shows a variety of screenshots and also has explanations from Timothy in it.
http://www.tweaktown.com/news/33368/slashdot-launches-redesigned-website-in-beta-form-we-check-it-out/index.html [tweaktown.com]
Honestly, I was impressed by at least some of the reasoning, and I can see how some changes would actually be positive. The problem, though, is that not all the changes are good, and it's far too much at once. There is a potential to lose what is special about Slashdot including its moderation system. They need to examine Beta and see and what needs to change for it to be accepted by the Slashdot community. Off the top of my head:
Here's a real and serious recommendation for Timothy if he wants Beta to eventually succeed without disrupting the Slashdot community: do redirections one day out of the week, and on that one day, have a story posted by Timothy asking the community for feedback -- one day each week for experimentation ("Slashdot Labs Day"). Then for the next 6 days, they can fix the site, while readers continue to use the classic interface. Keep doing that until the big problems in Beta are ironed out and the community is halfway satisfied with it. That is seriously a simple and reliable way that they could fix this and make people happy again. You can take that one to the bank. Unfortunately I don't know if they have the sense to do so because they haven't accepted feedback very well and they haven't kept in contact with the community.
Re:I hate Dice.com (Score:2, Insightful)
And I'm sure it wasn't Timothy who modded this thread "0 off-topic." No, he's far too busy listening to us and implementing our suggestions to have time to do downmods.
Re:Imagine (Score:2, Insightful)
SO TRUE! That's why he's getting the HP!
Re:BETA looks like any other news site (Score:4, Insightful)
Bees make honey. You can set up bee boxes and have bees live in the boxes and make honey that you can harvest. But the bees are free to leave at any time. They only reason they stay is because it is attractive to be there. Try making the bee box unusable and the bees will just go build a beehive elsewhere. Don't believe it? They've been building beehives for a lot longer than bee boxes have been around.
Re:Typical.... (Score:5, Insightful)
I would counter that this is reallly a problem with government IT contracts. In many government entities, at least the ones I've worked with, new projects are assigned to contractors/consultants and the existing staff handles maintenance. Often, the winning bidders don't even have the proper skill set and the contract includes training their employees. This practice started heavily after tightening budgets. Outsourcing was seen as a way to cut costs and in the short term it does, but not over the life of the project. The problem with this approach is that it leads to bloat and feature creep. The more the consultatnts can get you to expand your project, the more they make. Often, they tend to underbid the contract and overprice modifications, of which there are always many (if management new exactly what they wanted, they probably wouldn't need the contractors).
Prior to this, government entities had their own programming staff that was familiar with the business, the culture and what needed to be done. If a project failed, there were employees under your direct control that you could hold accountable. If the internal budget for the project was $X and it was now about to go over that, then there was some explaining to do. Employees worked to keep on budget and on time, because they, too, had their necks on the line.
For entities that still use their own internal staff, they tend to have less grandious projects, but they tend to finish on time and under budget, or at least closer to those two goals.
There is a myth that fewer employees means a more efficient and less costly entity. The reality is different. The myth is only true if the organization were over staffed and under performing to begin with, which is a management problem, not a worker problem.
The most common reason given for outsouricng is cost savings. But, outsourcing has shown, time and time again, that it is more costly in the long run. Contractors are paid more for the job than employees and the firm has a profit figured in. (Look at Snowden, he was paid double of what the equivelant network engineer that was a government employee was paid, plus the pay of his supervisors and the profit to the shareholders).
The second most common reason is that the existing staff doesn't have the skills needed. But again, history shows us that if the skills in question are really needed now, they will be needed in the future, too. Again, this is a management issue dealing with training, not a lack of worker skills. Besides, all of these skilless employees are going to need to somehow get the skills to maintain the software once it is turned over by the consultants.
Finally, the third reason is budget constraints. That is valid, however, only to the point that the projects are held to their actual budget. Since all of these projects that are outsourced tend to go way over budget and still have to be paid for because they are written as cost plus, claiming budget constraints is disengenous.
Managers do like contractors, because it gives them somebody external to blame for their own internal failures. It is a lot easier to fire a contractor than it is the person sitting in the cubicle for the past ten years.
In the end, if you want to reign in spending on a project (whether IT or otherwise), bringing it in house is shown to be the most economical way. OTOH, all of those mega consulting firms that lobby congress, don't let that message get out.
Adding new code is the problem (Score:2, Insightful)
If you think fixing the unspeakable new site with new code is an option, you probably don't understand the fundamental problems with it, aside from the look and feel. It ain't Slashdot. That's the problem.
Re:Typical.... (Score:3, Insightful)
Is your comment based on an unfortunate personal experience? I have worked as an engineer for two aerospace behemoths, with tens of thousands of employees at locations spread out all over the country. In both cases, IT was centralized, and that brought with it a high degree of conformity with respect to operating systems and common software tools such as MS Office; however, the engineering types didn't have any trouble at all in obtaining, installing, and using whatever specialized tools (including alternative operating systems) they required to do their jobs. IT's part of that was limited to procurement.
I now work for a much smaller company (< 800 employees), and the situation is similar, if smaller in scale. Everybody uses MS Office. IT uses Landesk to roll out Windows updates, but they leave my Mac pretty much alone, and they don't give a crap about the Linux box under my desk. They're a service provider, and they just don't get involved with the technical tools I might need and use, beyond processing purchase orders.
Balkanization usually doesn't have anything to do with serving the needs of the users. It's mostly about empire building and job security. The local tyrant can screw you up just as effectively as the faceless guy in another state.
At any rate, none of this has anything to do with NASA's issues, which appear from TFA to result mostly from a lack of buy-in from middle management. By the way, that doesn't necessarily mean that middle management should be buying in; it just means that there appears to be a lot of infighting going on.
There's another side to that argument (Score:5, Insightful)
I'd also like to point out that the failure rate of IT projects in general is very high (close to 70%) with little to no difference between in house and out sourced projects. I would add that a sizable portion of my work is refocusing (or replacing / undoing) projects that were started in house and went off the rails. I also know the flip side is also true - failing external projects are brought in house just as often.
There are several good (and some bad) reasons to bring in consultants.;
When you don't have the skills in house, or when your in house skills are fully utilized on other projects it makes sense to hire contractors. Contrary to popular belief, most IT staff do not spend most of their day playing Minecraft or streaming episodes of The Big Bang Theory at work. Most IT staff I'm familiar with work 50 - 60 hours per week and have weeks of backloged operations support and in house projects. Expecting them to add yet another major project off the side of their desk is a strategy for failure. Contractors (can) bring focus. I usually only work on 1 or at most 2 major project at a time.
Hiring staff for projects is not easy and not always the best idea. When you hire someone you invest in recruiting, training, benefits, pension, etc. because you expect that person to be with you, and productive for at least 3 - 5 years. If you hire people just for a project, at the end of the project you can end up with staff who are either under utilized or under motivated because their skills and/or ambitions are no longer what you need. Alternatively, you could end up creating projects with shaky business cases just because you have some in house resources. As a consultant, while I love to be re-engaged for subsequent work, I have no expectation of such. My best marketing is to get the job done. I usually include a post implementation review 2 - 3 months after the project. For me, this is a sales opportunity, but it is also an opportunity for the client to evaluate and learn from the implementation. This is something that doesn't always happen with in house projects.
When people say contractors get paid more than in house staff they are not seeing the whole picture. The things I mentioned above - recruiting costs, training costs, benefits, pensions, health insurance, vacations, paid breaks, statutory holidays, office space, admin support and HR support are all costs for internal staff that are either paid by or not applicable to contractors. Additionally, I carry errors and omissions and liability insurance - where the client company is entirely on the hook for the errors, omissions and liability risk of its employees. Finally, contractors can only bill hours actually worked on the project (or in some cases, a fixed price) where staff are paid regardless of utilization. When you factor all of those things in, experienced staff with equivalent expertise are often paid/cost more than contractors.
The biggest problem with outsourced projects is often in procurement. I haven't seen very many good procurement departments. They are often eith