Struggling With Major IT Projects 316
Ant writes "This article discusses the poor track record of IT projects undertaken by the U.S. government, and says experts blame poor planning, rapid industry advances and the massive scope of some complex projects whose price tags can run into billions of dollars at U.S. agencies with tens of thousands of employees. 'There are very few success stories,' said Paul Brubaker, former deputy chief information officer (CIO) at the Pentagon. 'Failures are very common, and they've been common for a long time.'... Seen on Blue's News."
Leadership is most important on large IT projects. (Score:5, Insightful)
It's harsh, but true. If these agencies had had better leadership and management, the projects would have been delivered, or at least never started in favor of something better. Blaming is on anything else is an excersise in passing the buck.
Re: Depends on what you call a leadership problem (Score:4, Insightful)
Are all of these 'leadership problems'? Sure, you can blame the leader of the project (or his leader) for those problems - after all, they should have seen them and fixed them.
But then all you've done is group a lot of problems together under "who to blame" and not tackled the harder problem of avoiding those pitfalls. So while I agree that leaders should stop projects from failing, the root causes of the failures are far more complex than just "leadership problems".
-Peter
Re: Depends on what you call a leadership problem (Score:4, Insightful)
Amount of resources and time allotted are both directly related to leadership. Leaders decide both of these things. Choosing the wrong implimentation could go to the tech folks, but solving the wrong problem is most certainly a leadership decision too.
I'm not trying to lump every decision on the leader and I'm not trying to say others can't screw up, but the cold hard facts are that projects that reach a certain size tend to fail because of things leaders should be taking care of.
Specifically:
Q. Who dicides how much time a project has?
A. Management.
But... what if the underlings give management a false impression about how long a task should take?
A2 This is management 101: Work with what you know about your people ans statistics about past projects to determine if they're proposing adequate time. It's TOTALLY a management failure if the amount of time given a project is wrong.
Q. Who decides how much resources should be thrown at a project.
A. Once again, this is TOTALLY a management decision. Yes your underlings may give you incorrect data to base this on, but if you're consistantly getting BAD DATA then it is a leadership FAILURE if you continue to believe the bad data.
Q. How do you make sure you're solving the right problem?
A. If GM builds a the wrong car for the wrong market are you going to blame it on anyone but GM leadership? If not, then why are you going to give them a pass on implimenting a network infrastructure that fails so meet their needs?
Leaders solve the macro problems of the company. Large IT projects are part of this solution. A large IT project is about as complex as building a new HQ building. Leadership does not allow new HQ buildings projects to fail. Why on earth are you letting them get away with not managing IT projects (infrastructure by defininition)with as much dilligence?
mod parent up! (Score:3, Interesting)
A. If GM builds a the wrong car for the wrong market are you going to blame it on anyone but GM leadership? If not, then why are you going to give them a pass on implimenting a network infrastructure that fails so meet their needs?
Excellent point! Somehow when things fail in a private company, it is always the fault of the "suits", while when things fail in the Gov't -- well, it was just too tough, and not enough funded (please increase my tax rat
Re: Depends on what you call a leadership problem (Score:4, Interesting)
Re: Depends on what you call a leadership problem (Score:3, Funny)
Re: Depends on what you call a leadership problem (Score:3, Funny)
The ones you want to look out for are the ones who get things done.
Look out for anyone who can get the trains to run on time - I bet you won't like the destination.
Re:Leadership is most important on large IT projec (Score:2)
After an initial project is agreed upon, the Government is notorious for changing features, designs, due dates as well as budgets. While leadership should just put their foot down and either say "no" or renegotiate, they would rather keep on the good side of the "G" and kill the project than lose contracts later.
Re:Leadership is most important on large IT projec (Score:3, Informative)
Re:Leadership is most important on large IT projec (Score:4, Interesting)
Re:Leadership is most important on large IT projec (Score:4, Insightful)
Without leadership, the people in the trenches would do whatever they wanted, anytime. They wouldn't have the right tools, they wouldn't conform to proper coding standards, they wouldn't be able to effectively meet with clients (think carefully on this one... Most groups will elect someone, aka: Leadership, to talk to the client.), there would also be budget issues, etc.
Trust me, I believe that the trench people (haha..) deserve a lot more credit than they usually get. The leadership though, needs to take care of the people in the trenches and thats what most businesses are missing these days. Hell, I worked for a company that provides a service to the government and I made enough to qualify for food stamps while management was driving around in BMW's and Porches - a classic Pointy Haired Boss company.
Its all about how you treat your employees. I've been fortunate enough (or unfortunate, depending on how you look at it) to work for a company that spoiled me when I was in the trenches. They made all of us at the bottom feel like we where the only ones that mattered and they where right. That company went profitable so fast and made so much money, it wasn't funny. Imagine being 19 years old and trying to figure out where you where going to park your Hummer H1 in 6 months while others are buying $200,000 houses with cash!
I've also worked on the other side of the fence for companies that are deeply rooted in the "Don't trust your employees" mentality - they happened to be an investment firm. They prided themselves on hiring the best of the best (top 1% that applied) but had an employee turnover ratio of over 26% a year... Oddly enough, they where very open about it in the interview and liked the fact that I brought it up. They felt it showed that I was truly interested in the long term... I bailed on them after 6 months for something better even though I was well paid.
Again, it IS about leadership. If leadership isn't doing their job, you don't like your job (or you just don't like working). Most geeks want to work for a cool company that works - lets use Google here... Why is Google so popular? Leadership.
You can't have Leadership in the Dilbert Zone... (Score:4, Insightful)
ERP implementation 1: At this place, there was something, let's call it the TPS report. It was supposed to be an automated replacement for a number of things that were manually generated from database extracts and number crunching. So, an interview with, oh, let's call her Suzy goes something like:
Me: so why don't you use the numbers from the computer?
Her: they are wrong, I use the spreadsheet from Fred instead.
Me: so what is wrong with the computer numbers?
Her: If I use the numbers from the computer, then the TPS Report will be wrong.
Me: so what is wrong with the numbers in the computer?
Her: well, the sales guys all get commissions based on what is in the computer, but that is not what actually got sold. Jeff places orders for customers, and the customers send it back for credit (called channel stuffing). So Jeff gets credit for the sales, but not penalized for the returns. George puts his numbers in 3 weeks late. And the VP, Ed, he just makes up numbers to meet the monthly quotas.
ERP implementation 2: At this place, the (mis)manager, let us call him Bob, decided that he wanted to keep 4 sets of books. Set 1 was the one that the IRS got to see. Set 2 was the one that the board of directors got to see. Set 3 was the one used to show to investors and the stock market. Set 4 was the real set of books. I told my boss that I wanted nothing to do with this Enron-wannabe. I won't work for SPECTRE, nor will I work for Enron. I had to quit to get away from the project. I understand they wasted over $8,000,000 trying to implement this evil piece of stuff. And they never understood why the numbers did not match. There is a solid reason for Sarbanes-Oxley, there are still a lot of companies who succeed at getting away with this sort of business.
As long as the people putting bogus numbers into the system had more political power than the people putting the computer system in place, the system was never going to work. Corruption and cronyism are not exclusively endemic to government. Most programmers are naive, they lack an understanding of the power that politics have over the way that work really happens. Stuff like the above 2 samples are why older programmers are cynical and sometimes bitter. Part of the reason that companies look for young programmers (under 30) is that those naive babes in the woods haven't been through the woodchipper yet.
If you hear of a "failed" implementation of some ERP/CRM system, dig deep enough and you will see things like the above samples.Only in America are people so naive as to say things like: let's leave politics out of this.
disclaimer: this is an encore posting.
Re:Leadership is most important on large IT projec (Score:3, Insightful)
My current manager tries to demand or demand features a week before deadlines and expects us to implement feature X in, say, 2 days. When I say that's not possible, we get into hour-long arguments where she says she doesn't understand why it can't be done in two days, despite having zer
Re:Leadership is most important on large IT projec (Score:3, Funny)
Not that I'm complaining, I work in France.
Management? (Score:4, Informative)
Peter.
Re:Management? (Score:5, Interesting)
Re:Management? (Score:3, Funny)
Re:Management? (Score:4, Informative)
great... but who replaces the bad managers?
my experience is that projects fail because of managers who get caught between two opposing forces, clients and tech staff, and can't broker a compromise.
the client wants a million features for next to no money and wants the product by thursday noon. since they're paying the bills, they can exert a lot of pressure on a manager. the techies want clear direction on technical issues that neither the client nor management really groks, tonnes of time and the right to overrule bad decisions made by the client. since the techies are the people who are actually doing the building, they have a lot of leverage.
when management cannot broker a compromise between these two positions, the project fails. i've seen management say 'yes' to every demand and timeline from a client, then go to the techies and say the client is clueless and stubborn and insist that corners be cut to meet the deadline. when the poject fails, the manager blames the techies and hands out some pink slips to mollify the client.
Re:Management? (Score:3, Interesting)
Re:Management? (Score:2)
If they pick an outsourcing company that just, sucks - then the company can say that they can't communicate with the workers... Of course, this still boils down to managaers by choosing a bad outsourcing company - or just choosing to outsource.
Re:Management? Not always... (Score:4, Insightful)
Examples:
- "we know it'll scale to 10k users, once we take the time to optimise it. We'll do that later" (project ultimately scaled to ~100-200 users max)
- "upgrading to the new version of tool XXX will let us solve lots of our problems straight away" (maybe so, but it added lots of new problems and dependency issues that blew the project out of the water)
- "we'll redo the crappy UI later" (not after you've made loads of incorrect assumptions about workflow based on a UI that already you knew was wrong, you won't!)
- "we've just attended a MS Web development seminar that told us our objects should be stateless, so that's what we'll do" (...to the point of having to verify e.g. user identity multiple times for each page loaded. This particular project brought down a country wide intranet when it was deployed, without prior testing because the developers thought "it wasn't necessary")
- "Bob's got that problem under control. We don't need to worry about it" (...until Bob, the single gun Tandem guy, left the company and we were left with a totally undocumented Tandem interface that nobody understood in the slightest)
- "that's OK; Microsoft are sending out a consultant to deal with that problem" (...sigh... Does no-one understand that the main job of a field MS consultant is to sell more software licences, not to fix problems?)
Every one of these issues was dealt with by a lead techo in the manner described above. Mgmt deferred to the lead techo in each case, and the projects suffered as a result.
Yep, I understand that you could call all these people "managers" rather than "techos", but each of these decisions was made on a supposedly well thought out technical basis. If these people are "management", then so are 90% of the people on Slashdot.
If we're going to characterise all management as PHBs, then why not also characterise all techos as:
- making incorrect assumptions, then extrapolating endlessly without attempting to verify the original assumptions
- assuming tools from Vendor X are golden (yep, I'm continually amazed how often this happens)
- relying on vendor X to provide a solution to problems when they occur, and not investigating workarounds in a timely fashion
- believing acceptable performance is always just a few code tweaks away
- assuming they know more about usability than designated subject matter experts
- endlessly reinvent wheels ("What? That object isn't a 100% fit for our problem? Better create a whole new one that works 1% differently and requires 1000 new lines of code to be maintained")
After 20+ years in the industry, I firmly believe that the best IT managers are those who have worked in multiple technical areas, as they can then see through the tech crap as well as the mgmt/project crap.
Re:Management? Not always... (Score:3, Insightful)
- "Bob's got that problem under control. We don't need to worry about it" (...until Bob, the single gun Tandem guy, left the company and we were left with a totally undocumented Tandem interface that nobody understood in the slightest)
That problem is entirely managerial. A
Re:Management? (Score:3, Interesting)
No. The closest to that is when the technical staff made a recommendation based on the data available from the vendor, but the vendor was over-hyping the product. I've worked one place where I was asked "will this work" and answered "no." So, since the management must remain blameless, they hired a consultant to come in and declare it will work.
I concur (Score:5, Insightful)
Re:I concur (Score:3, Interesting)
Re:I concur (Score:2)
Usually you don't get to the point of quibbling over the definition of "succeeding". The whole thing is scrapped and consigned to the bit bucket.
Re:I concur (Score:4, Interesting)
I would also say it's the management's fault entirely when the entire technical staff is saying that they should have dumped this POS and should have never started the project.
Example:
Where I work, we had a mainframe based system with some web enhancments added on. 99.9 percent of the whole thing was custom written with COBOL using very specific specs and used a non industry standard DB called DATACOM. It was developed over a 20 year period at least with parts of it being in service for almost that long. It was very stable and it worked and was able to serve the company well. Then, some management muckety muck who is not even there anymore, at the suggestion of the president, started looking for a entirely new system. One that the users would not be using a mainframe terminal session. One that was client server based in a period of time the mainframe was and still is at this point getting a resurgence. TGhis was about 6 years ago now. We are entering the third quarter with the new system and after only one quarter of production, we had to upgrad ethe production boxes spending another 500,000 to a million with implementation time taken into account. Now that the system is generally faster, users are mostly satisfied and the IT staff still isn't. Few examples:
One end of quarter process that took 30 minutes to an hour, running in real time with users still logged in to the system on the legacy mainframe. The new system? 2-3 hours or more and the system it's running against must be locked out from changes during the process because the realtime process can take DAYS!
Patches as delivered by the vendor regularly don't work. I don't mean that they don't do what they are supposed to do after you get them in....they just won't install. The version of the product we have is a hybrid of what it should be. It still has it's dependence on the older datatbase layer being there and thats just so it can translate it's programming calls to Oracle SQL calls. The systems course they provide to train sysadmins on the specifics on the application does not include about 60-80 percent of the new version of the product....and this product has been out for at least 4-5 YEARS.
We went from a mainframe to a system that has about 4 times of the power, yet the system STILL runs slower. This is even on VERY modern hardware and using 2GB fiber for the SAN. Sure, thigns are getting better, but this product we bought into absolutly blows, yet gartner (they suck anyway) and others STILL laud it as a good system We're not the ONLY ones to complain.
The deal here is, I would not be surprised if we stuck with it, but it sucks so bad I would not be surprised if they finally cannned it. We went from a very efficient system that if there was a problem with it, the staff knew EXACTLY what to do and now we have to make half a dozen phone calls to support...support that's only available for 8 hours a day on a system expected to run the company 24 hours a day. It could be weeks or months before we find a solution. The funny thing is, this thing was presented as software that would do everything, yet we had to write many custom modules and paid the vebndor to write several custom modules, non of witch worked on the INSTALL DAY! Even after doing post-install setup the program was delivered bug filled. We had a higher up in the vendor's company tell the programmers who are working on our part of the system and WROTE the majority of the old system that programming was TRIAL AND ERROR! WHOO!
And all of this was for the sake of dumping terminal screens in favor of nice purty client/server interfaces. We STILL are not to the point we were 6 years ago. We're closer today then we were when we initally launched, but was are so far off, it's going to take another 3 years and likely another hardware upgrade to accomplish what's needed.
Sometimes management should just leave well enough alone.
You should get scared if your manager starts bringing in books like the Tom Peter's Project '04 and Who Moved my Cheese,,,,
Re:I concur (Score:3, Insightful)
My point is that from time to time groups are asked (if not on purpose) to eat dog food for a few years. While it may be true that your new system might be a steaming pile that is destined for the trash bin it may also be equally true that the new system is a few steps toward a flexible, modern system that will carry your organization throug
Re:I concur (Score:2)
And all of this was for the sake of dumping terminal screens in favor of nice purty client/server interfaces.
Why not just write a screen scraper that uses the mainframe and presents a shiny new interface? Bet it'd be cheaper and easier to support.
Re:I concur (Score:2, Insightful)
Weeee! It's also fun when the datawarehouse is around the other side of the world and it goes down..
Its not an enjoyable s
Re:I concur (Score:3, Insightful)
Because we have about 10 layers of screen scraper type things, which is not fun.
It's not fun, but at least it works (in the scenario I responded to). I don't know your situation, but the other one looked like a political move more than anything.
Re:I concur (Score:4, Insightful)
I put the blame partly on managers in charge of the project that are too non-technical and distant from the nuts and bolts of what is going on.
Another factor is that the complexity of some of these projects is non-linear with respect to the 'size' (as say measured in the number of requirements). Government project managers should have a new mantra, something like "Small is achievable". The old 'divide-and-conquer' strategy, one of the first things you learn in programming. Break up the problem into achievable units and then use those to construct the solution. Sometimes the bleeding obvious is the first thing forgotten. Man, I'm just full of cliches today.
Re:I concur (Score:5, Insightful)
Big government IT projects, and government contracts in general, fail because there is zero reason for them to succeed, they are designed to fail. Big companies who live to drain tax dollars out of the government, like Lockheed [counterpunch.org], CSC or ESD can fail on project after project and they will still have a thouroughly good chance of winning new ones. The government rarely withholds payment even if the project craters. So if the government never punishes failure why would contractors care if the succeed or fail. The worst that will happen is a little bad press, they wont get the next contract for the department they just cratered but there are always plenty more. After CSC botches it, ESD gets it, they botch and then they will try CSC again etc. Same thing for Boeing and Lockheed. Thanks to merger mania in the 90's there are only two aerospace giants left and its not much different for every other big government contracting sector. The government has to pick one or the other of the big players no matter if they've cratered on contract after contract.
You really need to understand how these companies are structured. They are well oiled machines for identifying opportunities, submitting impressive proposals, using undo influence and landing contracts. They put their best people on winning contracts. Once they win it its another story. Then they are just putting warm bodies in there to fill slots and bill hours as they march through milestones.
The irony is a contractor will probably make more money if the project goes bad. If the project goes bad their contract will be extended year after year. The civil servants will just throw more money at the project in the hope that if they just put in a little more they will turn the corner and pull it through.
If the project comes in on time and on budget the contractor will make less on it than if it goes bad and overruns, so why should come in on time and on budget.
Consider Lockheed's F-22 as described in the link above. In some respects it an impressive fighter but at $300 million a copy it ridiculously expensive. It was supposed to be operational a decade ago but the government just keeps pouring more and more money in to though the U.S. already completely dominates every other Air Force on the planet with the much cheaper planes it already has. Lockheed can continue to develop it for another 20 years and may never field an operational squadron. They were punished for their failure with another $200 billion contract for the Joint Strike Fighter. They were just given a contract to build 5 or 6 Presidential helicopers for $1.5 billion dollars. Thats $300 million each for a helicopter.
Why does the government do it. Simple, the government/contractor system has devolved in to massively corrupt system. There is a giant revolving door between government, the military and these big contractors. The ambitious and greedy are only taking government and civil service jobs so they can establish connections and influence, do favors for big companies, retire from government and cash in a massive way with executive positions at those same contractors. Any Air Force general whose ever steered contracts to Boeing or Lockheed has a gold plated job waiting when they retire, where they can continue to influence contracts pulling strings with people who use to be below them in the chain of command.
Darlene Druyan is another classic example. She was one of the Air Forces' top civil servants for procurement. She steered a ridiculously lucrative contract to Boeing for 767 tankers, and before the ink is dry she gets a lucrative senior executive position at Boeing. Only catch is it was so blatant that Congress said enough is enough and damended the
Re:I concur (Score:5, Insightful)
That's naive, even for a "code like hell" mentality.
So, uh, I suppose you'd fire the guy who wrote qsort, or bit-torrent, or the tiny decss descrambler because they didn't turn in enough lines of code in a day? Heck, I've gone whole weeks where the number of lines of code in my CVS checkins were NEGATIVE (ie: added-removed). Not positive, not zero, but less than zero. Why? Because the guy that came before me was a sloppy hurrywort (or was being overly pressured by management to hack something out quickly) and I took the time to clean up the mess...
Features, requirements, stability, performance deadlines. These things matter. Lines of code? Everyone solves problems differently. Some of the best programmers write extremely small code. Then again, some don't. If you're going to be a technical watchdog, at least be technical about it. (Also remember, there's a good reason managers don't breathe down their engineers necks like they were two year olds... It's degrading, demoralizing, and likely to lose you the kind of self-motivated people you'd like to have around.)
Re:I concur (Score:2)
Corporations too. (Score:4, Interesting)
Re:Corporations too. (Score:2)
Re:Corporations too. (Score:3, Insightful)
Public corporations sure DO admit their problems. Then their stock takes a pummeling, people in charge of the failures might be fired, there's accountability for the failure in some way in almost all cases.
Now compare that to the government. If the blunder is serious enough, someone might be fired. But then they are right back asking for more money of my money to flush down the drain.
Re:Corporations too. (Score:4, Insightful)
This just isn't true. Corporations usually do admit their problems. They often have a legal obligation to inform shareholders about why their company lost $$$ dollars.
And besides, the Fed can afford to fess up. What's it going to cost them? If anything they'll get MORE money claiming they didn't have enough in the first place to make the project a success. Failure is almost always used to justify more spending. More money is the award for failure.
And it's not like the government is going to go out of business but companies that chronically screw-up will and people will lose their jobs.
Seems to me companies have a much greater incentive to make sure projects succeed.
Standard problem with all outsourcing (Score:3, Insightful)
Businesses trying to outsource their business application development also learn this the hard way. If your programmers are not intimately familier with how you operate, it doesn't matter how smart they are. Also, if you are trying to create a new way of operating, try experiments first.
Re:Standard problem with all outsourcing (Score:3, Insightful)
Sounds like the Feds need some Perl Hackers
Re:Standard problem with all outsourcing (Score:2)
This is true not just of governments, but of any large organisation bringing in an external resource to implement a project. I've been involved in projects more than once where the spec I've been given hasn't adequately covered the intent of the project.
In bringing in external resources there's so much scope for misunderstanding that problems will always surface. I've found the key (for me at least) is to ge
Also, Wired News reported this story too... (Score:4, Insightful)
Our state Department of Transportation... (Score:3, Insightful)
Our state Department of Transportation is rumored to have embarked on a PeopleSoft ERP/CRM project that has stumbled along for seven or eight years now, has cost the taxpayers something like $125M dollars, and has all of zero PeopleSoft modules up and running and functioning properly.
The "consultants" on the project are rumored to charge in excess of $200/hr.
Boy, I sure could use me a gig like that.
Re:Our state Department of Transportation... (Score:2)
That's Cheap (Score:2)
In the broadcast industry I know a consultant that charges $2,000/hr. Consultants generally charge a lot for two reasons. 1) They are highly trained specialists with 20+ years of experience. 2) They don't always have a contract and are self employed. (Taxes become much hihger in that case). On the other hand, this guy makes more in an hour than my boss does in a week.
hourly rate -vs- total hours billed (Score:2)
Or "they are likely to only get one week of work a month for 4 months out of the year" -- which could be the case in TV land. But still that's a killing.
Yeah, you often bill high hourly rates if you're not getting very many total hours.
But the "consultants" on this state DOT gig have been billing at around $200/hr going on EIGHT YEARS now.
If you run the numbers, you see how easy it is to get to $125M:
And that'
"Kaizen", the Japanese art of improvement (Score:5, Insightful)
This flies in the face of every software engineering textbook. Software, like flora, grows in its environment. Trying to introduce something brand new into an ecosystem is asking for widescale decimation of existing services as well as the increased likelihood of the introduced-species death.
So the key to getting working "IT projects" to succeed is to build on past successes. It's never the "Start from nothing, plan, implement" projects that do well. These typically go way over budget and way past the deadlines. It is the little "I need a little tool" projects that start off small and then are brought together or have extra features added to them that succeed.
Look at your bank's ATM system. When those machines first arrived, they didn't do half of what they can do now. It was through a gradual building upon what works and weeding out what doesn't that allows us the ease of personal banking today. Same with any system, even Linux. Linux started out as a small project to implement a Unix-like kernel. Now it is a huge business and the project itself is much larger in scope than the original idea of Torvald's.
Improvement, not creation, is the key to successful projects.
Re:"Kaizen", the Japanese art of improvement (Score:3, Insightful)
It's true that small projects are never huge failures (by definition). The problem with incrementalism is that eventually you wind up with a big hairball where trying to fix one thing breaks three other things.
Re:"Kaizen", the Japanese art of improvement (Score:2)
Re:"Kaizen", the Japanese art of improvement (Score:2)
Re:"Kaizen", the Japanese art of improvement (Score:2)
I'm not saying you can't/shouldn't reuse segments of the code, but putting lipstick on the pig doesn't solve the problem either.
Re:"Kaizen", the Japanese art of improvement (Score:2)
But what happened tot air traffic control? (Score:3, Interesting)
On of the classic big software projects gone bad was the failure of the revamp of the air traffic control system, which was stiched together with creaking mainframes and had old CRT terminals. The rewrite/redo/new system was a classic "Bridge too Far" (Operation Market Garden from WW-II a classic "massive rewrite" instead of an incremental approach. They were going to use paratroop
Re:But what happened tot air traffic control? (Score:2)
As I recall, they threw that $3B loser of a system out the window and shifted to a more modular approach. Now, instead of trying to develop a huge monster system that will be all things to all people, they're upgrading the bits and pieces one by one. One I remember hearing about was a modern controller terminal that could emulate the
Re:HOW, not what. (Score:2)
I believe that you can have success either way- it just depends on how it's implemented. There is some important groundwork to laid, either way - first and foremost, you need to have organizational "buy-in". In other words, if the entity you're working with is not on board (as in, unsure of what is going on, or resistent to the proposed changes), it's going to make things f
Re:The Japanese way isn't always the best. (Score:2)
underqualified people in charge (Score:5, Insightful)
From other articles about her, she was notorious in promoting her cronies, many of whom were also incompetent while passing over for promotion and bonuses those who knew what they were doing. Apparently Laura Callahan had a reputation for going ballistic when the occasional techie caught on to her and questioned some of her decisions. In hindsight, its rather obvious why she was so insecure.
Not really (Score:2)
Re:Not really (Score:3, Insightful)
I don't disagree - but using a false degree to obtain a job is fraud and does say something about the character of the holder.
Re: (Score:3, Insightful)
Re:underqualified people in charge (Score:3, Interesting)
Need to tell them what you want (Score:2, Insightful)
It's not the grunts, its the managers who have no idea what they are doings, and we wonder what the hell they are doing in IT.
It's not necessarily the managers... (Score:3, Insightful)
Most of us in the Development / Software Engineering fields see this on a regular occurrance. The same thing is probably happening here.
Scope! (Score:5, Insightful)
Projects are all about scope. Defining what it is that you're doing. Everone thinks that's bleedingly obvious... and they're right. But it ain't easy to do.
Once you're got the scope, the rest should be easy. But isn't. Another classic big project blunder is the lack of realistic funding and schedule. Nobody want's to say it's going to take megabucks and go for years.
So instead you end up with "it won't cost much or take very long". Guess what... budgets and schedules "blow out"! More likely they take as much and as long as someone who understood the aforementioned scope would have said in the first place.
Even when the basics are followed things go wrong. This is the final in the classic series of blunders. If something is starting to look bad - don't tell the project sponsor... we'll be right... maybe.
Big no no! Tell the project sponsor *now*! What's wrong, why it went wrong and how you intend to fix it!! You'll get more respect and less stress. Both of which make it more likely you'll get it sorted.
Ahhhh. I feel better now
Re:It's not necessarily the managers... (Score:4, Interesting)
The major problem is that management and techies do not fully comprehend what a lack of requirements means.
If open source is showing anything it is showing that release early release often is the way to go. Let the users pay with your system as early as possible and be prepared to change everything because it's doubtful they know what they want either.
Techies should be writing code that can be easily ported/changed/rebuilt/removed fluid software. The number of arguments I've had with other developers who want to build a system the one right way. Then they cry foul when the requirements change.
Managers need to get on board with the change culture. Requirments is at best a guess, don't go planning a release date based on them. If you have to implement on a fixed date then you'd better be ready to go live with a non-complete system. Plan for a release 2 etc.
Of course, we've known this since the 70s. I wonder how long before people realise that software should be configured not custom built.
The real reason... (Score:4, Informative)
They are trying to make all the solutions work... (Score:4, Insightful)
I think projects of that scope should stage such large developments, start with a general specification for the system and the desired end result and interoporability, then develop and roll-out modules progressively. As you debug the core modules and define the additions you can tune/revamp as you go. Then when you have a an unexpected problem with your thousand clients you are only dealing with a portion of the functionality not some monolithic spaghetti code. By the time you get to the end of the development you are working on a field-hardened platform.
Would it take longer or cost more? - well given the time and cost overruns of many of these big projects it might be more economical if not mre timely.
Re: Would success swoops work better? (Score:2)
They are trying to make all the solutions work in one fail swoop.
Well, no wonder it isn't working! Maybe the Fed should try the much more effective 'success swoops'...
-Peter "One swell foop" Hamlen
Perfect Example: NMCI (Score:2, Informative)
Re:Perfect Example: NMCI (Score:2)
Yes, it's harsh. But as long as users want to install their own software "just like at home" or do other things that risk security, secure networks must be physically isolated from others. No other method will ensure that Bob down the hall won't accidentally share secret information on Kazaa by accident.
Stupid users cause stupid policies. Add to that the military-bureaucratic mindset, and you've got exactly what the parent describes.
The biggest problem... (Score:2)
They took our research and gave it to someone who doesn't know much about
Some reading that might help. (Score:2, Informative)
This book is excellent:
http://www.iee.org/OnComms/PN/Management/Troubl e d_ IT_Projects.cfm
It contains much wisdom on the subject of major IT project failure and quite a lot of insightful material taken from notable historical project cock-ups.
I like the approach of identifying 40 common root causes (a good proportion of w
They aren't really failures. (Score:4, Insightful)
'Failures are very common, and they've been common for a long time.'
They aren't really failures. They are deliberate government corruption. Anything that has been "common for a long time", with no effective corrective action, is deliberate.
The IT corruption is small compared to the military procurement corruption, where the dishonesty can be kept more secret. The U.S. government is the world leader in buying equipment to kill people and destroy their property. (The least socially skilled way of relating to other people is killing them.)
U.S. citizens, it's 7 PM. Do you know what your government is doing? Unfortunately, you don't.
Re:They aren't really failures. (Score:2, Funny)
Poland! You forgot Poland!
It doesn't matter, and can safely be ignored? (Score:2)
"What you've described is common to all power structures."
It's not what you are saying that carries the most information in that comment. It is what you are not saying, which seems to be: "Since I've seen a lot of examples of corruption, therefore it doesn't matter, and can safely be ignored."
Gee.. (Score:2)
Large Projects Fail- Small Projects never get News (Score:2)
Smaller projects [google.com] succeed more often, involve smaller risks, shorter schedules, and faster results. Open source software development projects are an
A dilemma at the heart of the software engineering (Score:2)
Reinventing the same mistakes (Score:4, Interesting)
The second is a case where there are all kinds of intertangled, unnecessarily complicated business rules that are required or requested. Often these are dictated by legislation or attempts to "satisfy all stake-holders".
There should be some kind of bidding process on features such that features which gum-up the works will be charged to the customer somehow. Perhaps have a cost/benefit analysis/estimate be done on each feature, and chop off the ones that rank low (by being either too low priority or too costly).
Another thing I find totally lacking is any documentation of the design decisions. Before spending gazillion dollars on a fat project, the design and architecture should be seen and/or suggested by several expert eyes and every one of their written critiques and evaluations should be saved, whether used or not.
Then when a project succeeds or fails, one can see which ideas and/or which consultant/expert seemed to have the best insite or vision. Otherwise you keep reinventing the same mistakes over and over again.
Not just the US ... (Score:2)
Most of them go down big time, because companies take the government/taxpayer for a ride:
(sorry all links in german)
http://www.heise.de/newsticker/meldung/45522
htt
No accountability (Score:2)
One major factor driving massive failure... (Score:2, Insightful)
Any major public project that gets off track tends to stumble on too long because nobody is game to pull the plug - the political consequences are too great. For example, if a project is clearly hopeless, and has absorbed, say, $100M, it's difficult for a politician to shitcan it, because people will be up in arms at having spent all that money for nothing. They'll expect the government to throw more money at the project to finish it, rather than "waste" the money already spen
Learn a lesson from a success story (Score:5, Interesting)
Re:Learn a lesson from a success story (Score:2)
(prefarably US based for security reasons)
US based for political reasons perhaps. But for security reasons? Why would the developers need to have access to real data? They wouldn't. So you are proposing building a secure system via obscurity, and keeping that obscure information to citizens? Why do you assume that one of those citizens with obscure knowlage won't want to get fucked by some hot spy someday? Or want a pile of cash?
Re:Learn a lesson from a success story (Score:3, Insightful)
Not sure you you can really cite any of big supercomputers as really illustrative of how a company will perform on a big and
Mismanagement (Score:3, Insightful)
Basically, layers of layers of people produced by a hierarchical system that encourages mediocrity in ability and excellence in deception. Liars with superb brown-nosing skills and minimal ability leading skilled developers without those career-climbing skills. Recommendations from the knowledgeable ignored for reasons as petty as favouritism and wounded pride. Uninformed directives passed down. Valuable feedback distorted or disregarded going upwards. Career employees who couldn't care less doing the minimum they can and maximising the amount they seem to be doing. Burnt-out and defeated employees who believed once but can no longer care. Code and credit theft. Incompetents hiding their errors by sabotaging the work of others. Narcissistic managers who simply don't want negative feedback. Accomplishments delayed or distorted to fit the drip-feed system of delusional managers. Sacrifices of the innocent to protect the careers of the guilty. All held in place by a system that encourages all the negative aspects and hides it away in a nice, neat, convoluted bundle.
Did I miss anything?
And people are surprised that large projects frequently fail.
Someone's Loss, Someone's Gain (Score:2)
Missing The Point (Score:2)
Having worked for a large private sector business that sold its soul up the SAP river I know a little about how systemic this problem is. Managers foolishly believe marketing material and expect miracles. From what I have seen your best hope is to start a bunch of projects and hope a
Military 2-year assignements are a problem (Score:2)
This is just long enough to figure out that what's there is not working, figuring out what needs to be done, writing up the necessary paperwork, slashing through the procurement
Is immediate IP transfer the answer? (Score:2)
If the wheels come off a big project, the gov't typically pays much more than it anticipated, and/or ends up with problematic software. The problems are things like:
Private business (Score:2)
The problems have already been discussed (Score:2)
The problems of a terrorist tracking database have already been well discussed in Trevanian's classic Shibumi [mysteryinkonline.com]:
Software and IT ethics and morality (Score:2)
Add in the rampant anti-intellectualism in IT and management and you have a recipe for disaster
Re:Large IT looks like centraly managed economy (Score:2)
Are open standards engough, or do you need something else?
Put another way, if I had let all the people in my fictional Fortune 500 company choose their own OS, for example, how do I make sure everyone can get to the data they need when they need it?
Serious question, not an attack.
TW
Re:IQ (Score:2)
Re:IQ (Score:3, Informative)
Re:IQ (Score:4, Informative)
You've obviously never worked on a government program. Sometimes the oversight is all there is and the project is just secondary.
Re:Look at who has the problem. (Score:2)
Re:Look at who has the problem. (Score:2)
Congress can change it but they might have to limit their staffs to less than 20 and actually have to do some work themselves. Fat Chance. If you make less than $135,000/year you have NO representation in Washington. They only represent their own tax bracket and those they aspire to. Vote against all incumbants to so