Slashdot Mirror
Struggling With Major IT Projects
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."
The US government can't do anything right. Literally.
Major IT projects touch a lot of people. If you can't get everyone on board then the project is going to be very tough to complete succesfully. For that reason, the only real blame for "most" IT projects failing is leadership problems.
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.
The only IT projects that failed that I know are the ones that have bad managers... Most of the time that means someone who doesn't listen to the people that do the actual work but there are other reasons...
Peter.
I can only agree that very few large IT projects are succeeding. 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. They push the freight train on with the theory that the project can be brought in through determination and hard work. It can't. It has to be brought in by clever people who know what they are doing. And these manager types will push the train on till it goes over the cliff when better people would have known much earlier that the bridge was out.
The summary ignores that corporations are just as bad, but that corporations don't admit their problems. This is one area we find the Fed fessing up.
The largest commnist government have either failed orstarted to use market forces to grow. Large IT projects have similar aspects. I have been watching one of he larget the Navy Marine Corps Intranet from the sidelines for a while. It has been easy to throw stones after the fact, but it would have taken an IQ of 500 to figure this thing out. If I knew the solution I would not post it here...
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.
Click here.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
This is so sad that they would accept failure on such a large project. However it would appear to be typical. But try failing on your tax return.....
This message was brought to you by "Lack of Sleep."
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.
Many "managers" and "business folks" don't understand their domain. Their day usually starts off by covering up their lack of knowledge via politics, verbal diarrhea, and preventing the flow of information to those who are competent.
It all about driving that benz, looking good, and finding that special software developer to blame.
The basic idea of an "IT project" is to implement something that has never been implemented before, or to replace something wholesale.
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.
As the article noted:
Harvey and others said that while government technology blunders frequently make headlines, large-scale computer upgrades in the private industry fail almost as often. But these corporate blunders aren't publicized by congressional committees, federal investigators and inspectors general, they noted.
For some reason the poster chose to ignore that aspect.
This is what kills you. You can rarely roll something out into a *known* situation. You have to also support all kinds of junk and poor environments.
When a deputy CIO of the Dept. of Labor and than Homeland Security Department has bogus degrees and has never been officially questioned about her educational experience (or lack thereof) for years, its not hard to see how gov't IT could be atrociously run.
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.
With government programs there is almost (and many times) 0 oversite. For all they know the contractors are taking vacations to Jamacia with that money.
They wouldn't have any problems if they used Ada...you know, that language they spent so much money designing? It's really good for things like cost of development and cost of maintainence. The recent FBI flop of a case file system probably could've been started over half way through with Ada and finished on time. It wouldn't be the first time something like that happened.
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.
Most of my development experience tells me that IT development failures almost always are due to a lack of defined requirements. People *think* they know what they want, but they usually don't. And what they do know, they often cannot articulate. Kinda like the Supreme Court's view of pornography "I can't define it, but I know it when I see it."
Most of us in the Development / Software Engineering fields see this on a regular occurrance. The same thing is probably happening here.
Since when has anything in the US Govt. been managed in an efficient or intelligent way? I doubt if anyone in Washington can spell efficient. Bureaucrats are affraid to make real decisions, they might be held accountable. This is true of every Govt. job from mid level on down, and to some degree in the upper levels. They just try to generate enough paper to justify their existance, none of it has to make any sense or actually accomplish anything.
efficiency + Government = a bigger oxymoron than Military Intelligence.
Professional Politicians are not the solution, they ARE the problem.
The reason these projects are failures, or cost too much is because they are not being done out of need, but from strings pulled to dole out corporate welfare. Every industry the US is internationally competitive in (except maybe Hollywood) has (or had) most of it's R&D paid for by Uncle Sam - aerospace, the Internet, pharmaceutical companies and so forth. It's the old Keynesian thing of the government burying bills in old wine bottles and having some company come and dig them up. Government spending, which in the US usually means Pentagon spending, has been greasing the wheels of the US economy since FDR took office. The only difference between the two major parties is Republicans tend to want to build rockets/lasers that can shoot down rockets and that sort of thing, while Democrats want the money to go towards biotechnology and things like that. If you want to see what's going on, don't look at the end result and try to discern what went wrong, but look at the legislative process, and what pressures are in effect there. Billions of dollars was not really wasted - it made work for many people, imagine what unemployment would have been if it hadn't. It's the old bills in buried wine bottles story. I mean think of some of the ridiculous things proposed - billions for a "missile-defense shield"? It's just a way to spread money around. I don't like how the Democrats or Republicans do this, I have other ideas of how that money could be used for make-work.
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.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
The Navy-Marine Corps Intranet (NMCI) is an ongoing example of a federally-funded IT project that has failed to deliver. For over $6 billion, the Navy was promised a complete data, voice and wireless communications system that was fast, secure and reliable.The voice and wireless portions were vapor before the project even began. The data network is a discombobulated mess of machines with software that's already three generations behind and a level of bandwidth that's adequate at best and pitiful at worst.
To get a single change made on this network (move a user account, add hardware, etc) requires time, paperwork and outrageous costs. In spite of survey after survey of NMCI users who are unhappy with the new network, the Navy continues to push this as the coming thing, with the attitude at the top of "take it or leave." I've been fighting for months to get security groups built and shared data resources mapped in a way that makes sense to my users. Most of the are still sitting with two separate computers on their desks, connected to two different networks, just to get their work completed.
I also manage a small operational network that hasn't been forced to convert to NMCI yet. I'm trying to imagine what my users would do to me if I managed that small LAN and it's resources as badly as NMCI is managed by the contractor and the Navy.
I've just read a book on software business, and there was a quote from a Gartner Group (now known as just Gartner) study in 1986 that concluded that 85% of all IT projects doesn't meet the deadline. I believe this figure's still true. There are many causes for failures, but the main cause is bad project management. No matter how you twist and turn, the execution is a result of how it all was planned.
I've seen is that the government hires contractors to do the work, asks them for input, then totally ignores what the contractors recommend. As an example: recently, a group I work with was asked what it would take to improve the computer systems and build an identical setup for a hot-backup. We did our research, talked with vendors, and put together a proposal that we presented to the government (and we didn't even gold-plate it).
They took our research and gave it to someone who doesn't know much about computers (except how to turn one on). He promptly removed HALF of the items we NEEDED to fulfill their request. So now we have half of what we need and we're still expected to build an "identical" setup.
The only way you can successfully accomplish what you set out to do is with proper planning, adequate resources, and good leadership. We only had proper planning and that does NOT make for a successful project.
If "disco" means "I learn" in Latin, does "discothèque" mean "I learn technology"?
Primarily written for a UK audience, where we are well used to spectacular goverment IT project failure and runaway spending (ID cards? Erm, with your track record? You must be joking!)
e d_ IT_Projects.cfm
This book is excellent:
http://www.iee.org/OnComms/PN/Management/Troubl
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 which I've seen in my career, at least once), of course, most of them involve failure to communicate requirements and expectations during the early stages.
This stuff is mostly common sense, but of course common sense is always in short supply as the deadline draws inexorably closer and the project managers start to loose their grasp on reality...
'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.
If they took 10% of the time they spend analyzing&designing, and used that time to do actual work instead, perhaps they'd get somewhere.
In my experience doing IT projects for the govt., they simply can't be bothered to tell you what they want. They rely on you to come up with the requirements, and then after you build it they tell you it's all wrong and then finally start to give you some actual hints on what they were expecting. The problem is, there's no penalty to them/their job/their career for wasting tons of taxpayer money like this, so they just don't care.
Attention zealots and haters: 00100 00100
In all seriousness when a lot of the projects where originally anounced how many of use knew which ones would both fail and succeed (dependent upon the point of view). A interesting follow up would be about which external contractors where involved with which failed project and the revenue they were able to generate out of a "failed" project. You would expect that a lot of the external contractors were fully aware that the implmentation of these projects would fail but marketed them to the Govenment anyhow (after all a failure provides a second chance at the trough).
Chaos - everything, everywhere, everywhen
The Business of Software : What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad is another Excellent book on this subject. There's a lot of info on why software businesses and projects fail.
great. Now Bush is going to create a National Patient record system with this track record.
Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony.
IMHO, there is no incentive to perform well for the gov. Hear me out. I have worked on consumer projects, enterprise projects, and government ones. The management for the gov project was uninvolved and wanted the project to go long. They knew that the contract would be renewed so why come in under budget and on time. Job security. In the enterprise space I found that the quality of the software was poor for good reason. If a company buys an $8 million piece of software/hardware solution from you, it isn't going to dump you and buy someone else. They will happily pay to see you send 20 engineers over to get things working properly. The imagery is impressive. It says that this solution is very complex and only our "super engineers" can handle it. Plus it demonstrates great cusomter service. It blew my mind. However, in every consumer project I worked on we had very high quality and came in on time and within budget. Why? Because revenues depended upon it. All kidding about Windows OS aside, consumers will drop you in a instant if you ship a poor quality product and you will die a financial death. This kinf od dynamic does not appear in enterprise and government projects.
..I wonder why?
That Jesus Christ guy is getting some terrible lag... it took him 3 days to respawn! -NJ CoolBreeze
Smaller projects succeed more often, involve smaller risks, shorter schedules, and faster results. Open source software development projects are an interesting combination of small and large projects- essentially a small project (one coder, one mission, one plan) turned into a large project by the overall project environment.
I'd like to see Gartner Group say something about that, but I know they won't. The don't get any consulting coin from the OS community...
The "consultants" on the project are rumored to charge in excess of $200/hr.
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.
Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
Take whatever the price tag would be for a private company to do the same project, and multiply it by 10. Add pork-barrel tax (about 50%, give or take), and you have the government price. Not to mention it must take 4 times as long.
He used to say, "It's better to watch a cat choke to death on a hairball than to have an artery slashed trying to fish it out of his throat."
He had a fondness for animals, so it was ironic that he was killed by an albatross while researching giant turtles on Galapagos Island.
I thoroughly agree. I'm a project manager that used to be a tech. I become a pm because I'd worked under too many of them that had *no* idea.
:) These lessons came to me through the development of a fair amount of scar tissue. These days I never employ a project manager that doesn't burst into tears when asked about their worst project.
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
Forget the truth. Science is fact.
Business analysts don't get enough time with business experts because the experts are doing their jobs and can't spare enough time to pass on their experience. They're experts because they do their job well and can't be spared, and infinitely more so in a life-or-death job like law enforcement or counter-terrorism. And, because of this dilemma, things get messy. System architects can't plan the infrastructure accurately, developers can't code the application that the business experts want, and testers can't validate the system before it's handed back to the experts.
Is there a solution? The only one I can think of is a long-term effort on the part of the IT community to educate the business experts (and their supervisors and management) as to the value of automation in the jobs they do, get them to consider what it is they do and how they do it with the intention of automating the process at some stage. Have it as part of the business experts' jobs, throughout their careers, to consider how they will systemise and hand over their knowledge to other people. Also, everyone who is classed as a real honest-to-God business expert should have 2 'understudies', one to carry on their job while the experts are putting their thoughts in order, and one to figure out how to automate what the expert knows. The understudy to carry on the job will be tasked full-time on learning and understanding the role, but the one involved with the automation may be required to understudy more than one expert to make the process feasible. Systemised knowledge from the expert should reduce the time needed to come to a genuine understanding of the product to be created.
It's not an easy solution, and it may well have flaws that I haven't considered. If you can think of them I'd like to hear them.
One of the penalties for refusing to participate in politics is that you end up being governed by your inferiors - Plato
My observation is that is a combination of territorial office politics, automating bad processes instead of fixing processes, and not learning from past projects.
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.
Table-ized A.I.
There are large IT project failures all over the planet - not just the US. The UK had several big implosions and here in Germany we had bad projects like the Maut (satellite truck tracking system). Job database for Bundesagentur für Arbeit (unenployment agency for the government) and a big database of criminals for the BKA (like the FBI).
a rb eit/?id=532483
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
http://www.stern.de/wirtschaft/arbeit-karriere/
Take for example a simple job portal (like Monster.com or Stepstone.com) which costs about 163 million Euros! Actually most of the money was NOT spent on programming this joke of a system, but on consulting!
It seems to me that a major problem is accountability. If a major IT project fails, I don't see any of the people in charge in the government fired. I don't see the contractors put on the list of "people we are *never* hiring again". In fact I think in the UK at least the same contractor responsible for most of the major government IT failures is hired over and over again. Why on earth *should* these projects succeed when everyone knows that if they fail in the end they will not be personally held accountable and meanwhile they can get rich on slushfunds?
North American ATM's can't now do half of what Japanese ATMs could do 10 years ago.
-Work with coins.
-Dispense any random amount not just multiples of 20's.
-Transfer between differnt branc accounts.
-Carry out wire transfers.
There are probably valid reasons for this but I have always felt hamstrung by local ATMs since moving back.
If you don't want to repeat the past, stop living in it.
...is the 'sunk cost' fallacy.
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 spent, even if that means another $100M down the drain.
This phenomenon is so common that it gets mentioned in financial literature, though I'm too lazy at the moment to look a suitable reference.
It's an example of the sunk cost fallacy. The fact that $100M has already been spent isn't changed by spending another $100M that may or may not make things right. Most businesses are well aware of this, and will pull the plug as soon as it looks like a project is uneconomical. Governments, because they have to keep voters and oversight committees happy, are not so free to act.
What it comes down to this this: if a major government project is canned because of failure, it's a *good* thing. Failing projects need to be abandoned. It's the ones that drag on for years and become fiscal black holes that are bad.
With BlueGene, the US gov't approached IBM and told them "We want the fastest super computers in the world. We want to eventually reach the the Petaflop range. Here's some money. Do it" and IBM happily complied. Late last year, the BlueGene/L prototype recaptured the title of world's fastest computer from the Japanese. The BlueGene/C design is due (on time) in June and should be available from the foundry in August (full discloser - my grad work involves testing & verficiation of this). The lesson? Where IT is concerned, the Government has a legitimate interest in outsourcing it to reliable companies (prefarably US based for security reasons).
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
Mismanagement. Same as large projects in commercial organisations.
;)
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.
The Japanese software industry works like a factories. Not much innovation, mainly production. I'll give them credit for their quality though. They produce way less bugs than western or Indian programmers for that matter. Read Michael A. Cusumano's book Japan's Software Factories: A Challenge to U.S. Management. Google has more.
It is also worth mentioning that a number of Government IT projects "Succeed" only because the politicians sponsors of the project can't afford the project to fail (they may be of almost zero use in the real world, but success is still claimed). In these situations contractors are normally able to get extra money to help make sure the project appears to succeed.
What is so valuable about American engineers that makes them worth so much? For all intents and purposes, most programmers are just a cog in a much larger machine with replaceable skills. There is a lot of preening of programmers, especially on this site, and a tendency to see onesself as an "artist" that "crafts code" rather than a worker with some specialized knowledge.
I'm not saying the Japanese tendency to underpay engineers (or any employee, for that matter) is good. But when the numbers are really analyzed on the Salary vs Profits Generated ratio of the average American programmer, you find that not only do they come up very short, you also find that for the cost, the quality really isn't very good either. Which begs the question, why are they paid so much in the first place?
Some projects fail because they don't have enough resources, or not enough time has been allotted. Sometimes, the project planners choose the wrong implementation or try to solve the wrong problem. Sometimes, projects fail because the users don't really tell you what they want.
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
Hey, the $170 million the FBI "lost" in funding the overhaul made SAIC (the vendors) $170 million richer. So I guess that's a good thing, right?
Vincent J. Murphy
Spandex Justice
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 at least one produces somthing useful. But this goes in the face of ERP.
I guess I'm saying that you should view your business environment as an ecosystem and make sure you maintain enough (software) diversity in the system to hopefully overcome any obstacles.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
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 paratroopers to capture a whole lot of bridges in Holland, and then the main body of the army was going to come motoring through all of those bridges and straight into Germany to end the war. The main army got bogged down at the first bridge and the British 2nd Airborne Division got hung out to dry at the last bridge, and a British general offered up British understatement as to why the whole plan failed as "it was simply a bridge too far."
In the case of the ATC rewrite, they concentrated on the ATC controller workstation -- the thing with the big CRT where all the flights show up on radar but with alphanumeric info added -- but it was going to be the ATC workstation to end all workstations, and it got caught up in a mire of specs.
I surmise that it was supposed to be a massive bitmap graphic CRT back in the day when megapixel bitmap graphics was bleeding edge, and it was supposed to customized, both for the preferences of the controller as well as the geography it was to cover using some kind of configurable software, back in the day when people hadn't heard of OO and GUI frameworks.
I always thought they should have done something incremental, but I guess I never understood their problem domain well enough to know what incremental would be.
But what ever happened to ATC? Are they still using battleship CRT monitors driven by creaking mainframes? Did they come up with something that works using newer technology?
The main problem with government run IT programs is the same problem with ALL government programs.
Oversight and other things are the only tip of the iceberg.
The problem is they are being created BY the government. A Government may be penalized by voters for screwing up, but the likelihood of that transcending partisan politics is miniscule. A Corporation is screwed if they mess up, they will lose money, etc. All a Government has to do is request more money.
Look at projects such as the Big Dig (in Boston), they've run 5 years over, and nearly 14 billion over budget.
How does this apply to IT? As I mentioned, the mentality is the same.
I'm kinda surprised nobody's mentioned the FBI IT fiasco yet. The FBI had a plan to overhaul their computers/network, and its millions of dollars over budget, and doesn't even work.
To finish my argument, I quote the Department of Justice's Inspector General, who blasted the FBI IT project.
"IG investigators concluded that the bureau lacked basic project management practices and had failed to establish policies that would prevent overruns and delays in IT procurements."
For the terrorist-tracking system, just get a big-ass Oracle RDBMS, typical add/change/delete/query-by-example/ACL user-interface tools, Crystal Reports, and put in the following schema:
// table name // auto-gen // Priority risk assigned to suspect // reason for being a suspect
//auto-gen // foriegn key to "suspects" table // used from date
// auto-gen // start date at location
// ID of agent authoring note // if applicable (see below) // text note for small stuff // document reference (such as MS-Word file name)
// meetings or close encounters between multiple suspects // auto-gen encounter ID // date of encounter // foriegn key to "suspectLocations" table
suspects
----------
suspectID
priority
suspectReasonCode
suspectFirstName
suspectMiddle
suspectLastName
suspectAliases
--------------
aliasID
suspectRef
aliasFirst
aliasMiddle
aliasLast
usedFromDt
usedToDt
suspectLocations
----------
locationID
suspectRef
locatFromDt
locatToDt
locType (residence, airport, hotel, etc.)
longitude
latitude
(insert typical address columns...)
fieldNotes
-------------
suspectRef
agentRef
locationRef
encounterRef
textNote
docRef
encounters
------------
encntrID
encntrDescript
encntrDt
locationRef
encounterParticipants
-----------
encntrRef
suspectRef
fromDateTime
toDateTime
I'm done. Now where's my 30 mil?
Table-ized A.I.
A number of causes often lead to disaster: 1. The government procurement regulations are often more concerned with minority ownership and 'fairness' then they are with getting a competent contractor. As observed, the initial contractor that does the project specification is often not the contractor that gets to implement the project. 2. The government contracting officer often has no technical training is is essentially clueless in the subject matter being discussed. 3. The systems being replaced have often been in place for many years and have been tweaked and fine tuned to make them do what the end users need to have done. The people that were responsible for design and tweaking have long since retired and there is nobody who understands the totality of the system being replaced, nor the interaction of its parts. 4. As noted, the upper managers who decide on these huge projects are frequently clueless and are driven more to purchase what the nice Micro$oft salespeople want to sell them then they are to field a working system. By the time their bad decisions come home to roost, they are long gone. 5. The projects are usually grossly underestimated and underfunded to obtain initial approval. By the time the true cost of the project is understood the managers have moved on and some poor 3rd level manager is left to pick up the pieces. 6. The worst part of it is that when the project fails, the Government agency is left with an obsolete system that is now 10 years older, the taxpayers are holding the bag, and the cycle needs to be repeated with greater pressure and urgency. (For another example of a failed largescale computer system project, check out the Veterans Administration's COREFLS replacement project which almost brought the Bay Pines, FL VA hospital to a halt: http://informationweek.com/story/showArticle.jhtml ?articleID=18402842)
Shamelessly picking on the innocent typo:
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
They caused the Darpa/SEI institute to try and improve things, a decent effort with the CMMI etc, and have been reporting some measure of success, but the effect is limited, because they cannot address the root cause.
There are some confusing red-herrings:
Both these factors, while arguably true, are just confusing misdirection. IMHO, the root cause is that there is a negative selection effect in play.
Contractors that complete on time, on budget, or to spec, will make significantly less money from the contract than those that don't. Ultimately, natural selection, causes the wealthier contractor to absorb the smaller ones. Simply put, its survival of the least efficient.
So long as a contract firm can reasonably claim changes in requirements caused the delay, they can extend projects indefinitely, until it is so outdated it gets scrapped (and a new one arises, to replace it). There is never any internal criticism or consequences within an agency for staff changing (or omitting to state) requirements, no one gets fired or even given a poor performance rating, its just accepted. Everyone knows change will mean more jobs for more years, so this unofficial strategy of never ending changes is chronic, the agency will play along.
The real motivation is keeping agencies and services charitably engaged employing people. It has nothing to do with IT, or technology failure, We geeks are merely the public scapegoats, convenient doormats, we usually dont care, cos guess who is gonna get hired by the contractor.
Many RFQ or RFC do not appear to specify any actual requirements or specific objectives, thats usually left to the successful bidder to define and discover. Crazy but true. They may claim to specify stuff, but in my experience the acquisition documents usually do not include these basic items of information. Its hard to discover this as you have to dig through reams of deliberate obfuscation, missing references, and changed links, but in my small sample it seems to be true.
Fixing this situation is effectively impossible. It requires removal of the economic drivers causing this un-virtuous circle. There appears to be no real political motivation to change the basic economics, no politician seems to be influenced by wasted taxpayer money anymore. Or, put another way, the taxpayers can be manipulated so they dont care that the politicians dont care.
So, I conclude that this situation is effectively permanent, it will never get fixed.
If you can't beat em, join em?
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
A degree means nothing---absolutely nothing---in determining whether someone can do a job. Educational experience means nothing in determining whether somone can do that job, either (unless said job is Education, but then how many Profs have you had that couldn't teach their way out of a web paper sack? I thought so).
Yeah, right.
I actually live and work in the Washington, DC metro area, and I have been involved in many government computer projects, both with my current company and with other companies. A serious source of problems is the military's personnel system that assigns an officer for two years in a particular position, and then he or she moves on.
:-( Then the next officer comes in and goes through the same process, only she's an Oracle girl instead of a Sybase girl, so she re-specifies the system the way she wants it to work, etc., etc. Lather, rinse, repeat.
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 red tape, fiddling with the service politics involved, getting a prototype up initially, converting part of the operation over to the new system, and packing up to leave.
This is in no way a slur on the individual officers, by and large. Most of them (indeed, almost all of them that I have known personally) are dedicated, smart, hardworking individuals who are responding rationally to the incentives thrown at them by a screwed up system.
--Paul
A big part of the problem is the way the Government negotiates contracts. After years of working for a contractor I am now convinced the "Software Crisis" is basically a negotiating plow. It's common for the government to ask for bids on 10,000 or a 100,000 units when they know that they will be buying only several thousand. Sure enough, if you buy 1/10 of what you initially ordered, it's gonna cost 10x more per unit. Either they don't understand business or they are doing it just to get as low a bid as possible per unit cost.
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:
I think that there is way to avoid a lot of these problems. First off, the large IT projects need to be broken into smaller chunks. Second, there needs to be a much stronger emphasis on using open standards within and between the chunks. Third, there needs to be a strong requirement for contractors to reuse existing open software components.
Finally, (and this is the important part!), IT project contracts need to be written in a way that makes all software (etc) immediately become the property of the contracting party (e.g. the gov't in this case). (In the current model, ownership of software is only transferred at discrete signoff points following an acceptance process.) This means that if the wheels DO come off a project, the contracting party has (and has had) better visibility on the technical problems. In addition, they have more chance of getting someone else to put the wheels back on. Finally, they have more leverage over a shonky contractor who does poor quality work. (XYZ corp is less likely to get new work if the crappy code they develop on the "Lead Zepplin" project is put on public display.)
Obviously, this kind of arrangement puts extra risk on the contractor, so it would be reasonable to reflect this in the method of payment. For example, the contracting organization might pay for work in smaller increments, and possibly ahead of time. While this would appear to push more of the project risk back on the contracting party, it is likely also to reduce the overall of a complete project failure. In particular, if the contracting party is paying in advance, it has more incentive to adjust project scope/requirements if the project start getting difficult. (And they have more opportunity to see the problems early.)
Obviously, the contracting party can still get burned by a project meltdown. But if they are on the ball, it should only be first degree burns ...
Alot of the problems described as leadership problems are actually political. A project might not be able to survive if a few powerful people want to kill it.
Some projects fail because they don't have enough resources, or not enough time has been allotted. Sometimes, the project planners choose the wrong implementation or try to solve the wrong problem. Sometimes, projects fail because the users don't really tell you what they want
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?
The trouble is that this was a replacement for a true enterprise system. It had about 200 database-to-database external interfaces that need to talk to one system, not some of the old and some of the new. The business rules were, essentially, the Federal rules of evidence, which can be changed with no notice by Congress or the courts, but had to be right or defendents walk. There are tens of thousands of users who are perfectly happy using paper, but might give you one shot to convinced them that the system is worth learning.
This system could not be deployed piecemeal.
Get rid of the brokedick government service (GS) managers that lack progressive thinking. Many of the management types in the governement IT world depend a lot on his/her previous military experience to manage. This military approach, in the majority of failing modern IT projects, simply fails. The RNOSCFE (formerly known as ITSCFE) is experiencing this first hand. There's seems to be no end insight to this MAJOR oversight.
I'm really not sure that private business does much better. I've been involved in a lot of projects where we get done and then for a variety of reasons the new software doesn't get fully used. I've had an entire year where, if I had bluffed and done nothing the entire year, it would have had the same effect. The only difference in the scale. I suspect if every IT project undertaken by corporations succeded 100% every time, that the average IT staff could be at least halved.
My Weblog
all of these gov IT popel know that are doing crap.. how come no one ever syas.. lets scrap this project... if they do and dont waste tax payer money there is no need for IT person and those gov it workes that cant hack it in the real worl would much rather keep their great gov benefits.. you slashdotters need to lear from the asutrians.. www.lewrockwell.com .. www.mises.org
http://shit.slashdot.org/article.pl?sid=05/01/30/2 320222
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's just one "consultant".Frankly, given that it's a state government agency, it strikes me as nigh unto felonious. [In fact, I'm a little curious as to why it hasn't become a campaign issue yet...]
Several times I've worked on projects where "the people doing the actual work" (i.e. techies) have been responsible for the ultimate failure; they've been given too much authority and made decisions that've ultimately sunk the project.
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.
"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."
Bravo sir, bravo. You have just summarized my life in IT up til I retired a few years ago.
The basic idea of an "IT project" is to implement something that has never been implemented before, or to replace something wholesale.
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 far worse. Second, if you use methods like parallel implementation over "turning one off and the other on," you will be afforded an experience where things are much more resilient when stuff goes wrong. This may sound like common sense, but based on what I've been hearing about a particular project recently, I'm willing to bet that it isn't used near as often as it probably shoudld.
Reading this article, looking at the Politics-Oriented Software Development, and going through the changes at my own job; I have realized that IT is an artistic design and adding a bureaucratic approach is a recipe for failure.
At my current job, I am swamped with TTPs (not to be confused with TPS). Anytime a user calls asking for data, a program change, a new program, etc.;
1) I have to have to log the call.
2) I print out a TTP and have the user sign it.
3) After the user approves, I have to have my boss approve the change.
4) At this point I can fix the problem.
5) After the problem has been fixed, I have to mark the item as fixed in the logging software.
6) I then print the 2nd TTP for the task.
7) I have a developer test/verify my work.
8) The user tests/verifies my work and signs.
9) I give the document to my boss to sign and image the document.
10) My boss closes the item.
The former approach was
1) A user calls with a problem.
2) I fix the problem
Granted this is poor management, but anytime my boss is questioned about this; he blames Sarbanes-Oxley. All I know is this is killing my productivity, so I am sure that even under good management government projects are destined to fail.
Languages such as Java and Visual Basic allow computer novices to call themselves "programmers." (or more arrogantly, "Developers"). The solution is to get rid of these baby-talk languages so that only qualified experts will be able to program computers.
I know that is a controversial statement, but when you reflect upon it you will realise that it is true.
From my own experience I've seen project after project screwed because there was no one person in charge, and that people above and adjacent to projects had to get their imprint on the project in some way before it went live.
Let's face it, the Federal Government isn't run like a business. It also has little to no real accountability, and anyone brave enough to be in charge would insist on having a committee around him or her to make sure blame could be spread (or transferred) around if something goes wrong.
Another aspect to this isn't that the DEVELOPERS wanted to have a hand in how it worked, behaved, etc...it's that because of the need to seek 'consensus' between everyone at every level involved before it even gets to the developers (and because of the fact that administrative committies are so large in the gov) that requirements on nearly every project change. Forget the developers even having a hand in this. Requirements on these projects change in mid-stream and end stream all the time. They do it, and it extends the life of the project. There is rarely one visionary (or one real point of contact) in the gov given the rights to control how a project is to be built, resolved, etc. In the end, it's a flustercluck, and no bones about it.
"Love is like pi - natural, irrational, and very important." (Lisa Hoffman)
The problems of a terrorist tracking database have already been well discussed in Trevanian's classic Shibumi:
Q. How do you make sure you're solving the right problem?
;-) ), and this and that.
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 rate!
Comparing the waste of the modern Big Gov't to the reasonably (if only sometime inefficiently) run corporation can be eye-opening, but most of the people here would prefer to close their eyes shut for whatever political reasons.
Paul B.
You know, I used to be like you - saying that the people in the trenches are the ones that make things happen, but I found I was wrong after starting a business. I bet you're currently in the trenches and have never been in upper management...
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.
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?
IMO, new HQ building projects fail all the time. The difference here is that marketing and spin usually take over to make everything a success - a building is a blot on the landscape for a long time after all. Frequently by the time the building is completed the requirements have changed and that building is too small, too big, or whatever.
The public seems to want IT projects, especially Government ones, to fail. It is easy to blame the computers (and Governments) for everything.
I have said this before and at the risk of sounding like a broken record will say it again: If you sold used cars like software is sold, you would be in prison. If you sold real estate like software is sold, you would be in prison. 'No' is not an effective sales tool, so sales droids end up selling vaporware with poor requirements. 6 months seems to be the magic number, whatever it is it can be done in 6 months.
Add in the rampant anti-intellectualism in IT and management and you have a recipe for disaster. Example: Denver International Airport was required to build an automated bag handling system. It failed miserably. After a brief discussionwith a freind of mine it occurred to us that what is was is a routing problem (to send bags from terminal A to terminal B and to the baggage carousel, possibly changing destinations in real time). If you are familiar with routing problems (and anyone with a degree in CS or SE SHOULD know this) you will realize it is a very hard problem, possibly intractable with computing machinery. DIA mangement did not know this and either the contractor was incompetent or unethical (there being no profit in saying 'No').
As another example, see the article at http://www.cio.com/blog_view.html?CID=935 for an anlysis of ERP failures.
An organization I once worked for was scared into an ERP roolout by Y2K. They dumped, at great expense, a mainframe application from another vendor which worked for years beacuse it was not 'Y2K complaint'. Well, as FY2K approached the ERP vendor announced that the product that they had proudly sold as a Y2K solution was not Y2K compliant! They had to push out a huge number of patches at great expense to their clients at the last minute. Meanwhile, the mainfram application vendor had quietly patched their system so that it was Y2K compliant.
Anyway, these are all reasons why I am throwing in the towel. I am retraining to get out of IT and hope to be done with it 3 years. When I see charalatans making money and good companies being punished, there is only so much I can take.
putting the 'B' in LGBTQ+
Just to add to this, while leadership is mostly to blame, the Government can be a very bad client as well.
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.
"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."
Most people are familiar with the 34% success rate of projects, as reported in the Standish Group 2003 Chaos Report. Whether the success of your project depends upon juggling hundreds of details, or hundreds of thousands of details, there are two basic ways that projects fail. They either fail completely - delivering nothing of value, or they fail to deliver a significant portion of the benefit that they could have yielded.
Download your own pdf copy of this Special Report:
Why Projects Fail.
From: http://www.projectsdoneright.com/pdr/pdrPapersWhy
The US government (appears) to be singled out for IT projects gone really wrong. I have (as a Canadian) an example of an IT project gone (really) wrong. Sadly, the money pit hasn't ended. It's called "The Canadian Gun Registry" officially, but is otherwise a money pit, and a bad joke. They had spend 4 billion Canadian Dollars (3,227,903,567.73 US dollars at the current rate of exchange) on the system by the time they determined that the system was under powered and none of the equipment could be salvaged. Thousands of new computers (complete and in the box) were decomissioned on arrival. The database proved to be ineffectual and needed to be replaced (very high transaction times), and data storage whose capacity was not nearly large enough, nor any of the equipment fast enough to operate effectively. What a waste! (There is the little issue of whether you really expect a crimminal to register a firearm, but that is another debate). The US taxpayer may have a reason to be angry, but should by no means feel alone! Grrrrrr
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.
Oh, they do that often enough. Then you find that you've developed and debugged all the core modules and you have run out of time and money without actually producing any new functionality.
This project is classified as a failure.
Modularity doesn't help. Monolithic construction doesn't help. Only budgeting time and money correctly, and then producing the project within budget, will help. The problem is corruption and incompetence; different design approaches, regardless of the approach, are not going to solve it. It's not like the people doing the work have any particular incentive to succeed anyway; they'll get paid regardless, and, contrary to what capitalist propaganda would have you believe, they'll get the next contract regardless. Market forces are unreliable at the best of times, and they do not function at all for government contracts, which are awarded for political reasons and nothing else.
The problems are not new or poorly understood. Nor are the solutions difficult to see. But there is absolutely no interest in implementing them. This is politics, not engineering. Success is not important to the politicians who make the decisions. Rather than expending resources to succeed, they can lie to you and tell you that they want the project to succeed, for the same effect on their reelection prospects. There's usually more going on than this, but in the trivial case it comes down to a choice between company A, who will succeed for a given amount of money, and company B, who will fail for much less money. The politician will choose company B every time, because failure doesn't matter to them; it won't happen for ages, and it's not their fault.
Well here is one side of the dilemma: how many times will a manager listen to a "lowly" programmer? Ummmm that would be exactly 0. Managers don't need to talk to any of those 'people', and certainly don't need to listen to them! Gartner has people with bucketloads of solutions (for bucketloads of money). They have the ear of manufacturers (and possibly the sales brochure). No manager wants to hear about how it works from some 'greasy haired coder guy', they want the guy with the power suit, power tie, hair greased so well that if he were ever to slip and fall a dangerous goods team would have to decontaminate the ground where his head struck, complete with gucci loafers, gold necklace and watch. One has an intimate working knowledge of not just any system, but "The current running system with all of it's needs", the other has an idea of what might be needed, along with some idea of how it's supposed to work (at least with block diagrams and powerpoint pictures). Of course the manager would pick the salesman, coders can't afford to take the boss on a power lunch!
1) Starting a project from scratch staffed by only inadequately experienced developers;
2) Changing members ( managment and programmers ) in projects that have failed to fully document the project;
3) The Vendor Dependent Death March : When in house projects are dependent on proprietary vendor specific APIs/functionality then the project is almost guaranteed to fail when dependent vendors either fails to deliver or changes/breaks the API used.
IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.
Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).
One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.
Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX . Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard basealso offer a cross vendor foundation.
The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package]
). The distribution/OS Vendor can then ship conflicting versions of
dependent packages without it breaking the project code. The in house
developers can then test and port to the new version at their leisure.
Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.
When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.
If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.
Repost
I've been involved in a couple very large government I.T. projects in which the govt organization was very clear what they wanted in their RFPs. Problem was that none of the vendors wanted to sell and implement the systems the way the govt desired, because what the govt wanted was thouroughly, and thoughtfully designed and implemented systems that would have a useful service life expectancy of 7 to 10 years without any "forklift upgrades" (like what used to be the norm back in the late 1980's thru 1990's) but all the hardware and software vendors these days deliberately design in plenty of forced premature obsolescence and interdependencies of components with deliberately short-lived product lifespans in order to capture the customer into a situation where they are forced to have to repurchase most of the hardware and software every 2 to 3 years just to keep the whole system operating.
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".
Agreed!
Were I to pick one factor that makes the difference between successful projects and failing ones, it's frequency of release. The only way you really know whether your ideas are worthwhile is once they're in the hands of the users. Projects that find that out every few weeks can't go far wrong. Projects that wait years between having a theory and testing it in the real world are, from what I've seen almost certain to be doomed.
You could call that a "leadership" problem, I supppose. Instead I'd be more likely to call it a lack of humility.
experts blame poor planning, rapid industry advances and the massive scope of some complex projects
Any project of size requires planning. The problem with government projects is that the size and scope requires too much time. They have to be completed with changing requirements as political climate changes. They are almost always implimenting technology that was either created by the government at great cost, or off the shelf hardware and software that is obsolete before the planning stage is even complete. On top of that, the red tape present in any bureaucracy when forcing change is formidable, and it takes a lot of money to get through. It would be cheaper to just bribe people, but we have to pay off entire departments to get them to go along with the IT plans.
If it were ever as simple as "here is your project and your budget, have it done in two years and let me know if anyone gets in your way and I'll take care of it," then they'd be as cheap and easy as in the Real World. But when you are trying to impliment change in an organization designed to minimize change, you will have an uphill battle.
Learn to love Alaska
Sounds like your company could have used an web interface to please the "management" and end-user "want/need" for a GUI that was more modern. I know we have created WEB GUI's that look as good as client/server while still being Server side.
Bravo sir, bravo. You have just summarized my life in IT up til I retired a few years ago.
:) I just summarised my last five years and it just wrote itself. ;)
Why thankyou.
I have found projects fail more from bad managers then anything else.
The single formula I have seen for failing is treating the trench people like resources and not humans. As well as sucking up to higher managers/customers and supplying the workers with unmaintainable project requirement/dates and then changing it while working on it.
A good example is costing. Your trenchies will know what is able within a set time.
A good project I was on the manager asked everyone to do a costing document of how much each feature would take to do. The manager then worked out what features we could do.
A bad project I was on we were for example given 20 days to do a feature the manager wanted. I asked why there was no costing document, the reply "Ok cost the feature to 20 days". When the costing showed it would take twice that time she started to remove parts of the costing to get the time down but not to change it (eg. Unit Testing+meetings removed from costing yet still expected).
Several times I've worked on projects where "the people doing the actual work" (i.e. techies) have been responsible for the ultimate failure; they've been given too much authority and made decisions that've ultimately sunk the project.
- "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. Assign Bob a backup. Failure to do so is entirely managerial. What it seems you are mentioning are poor management decisions made by technical people. Why are the technical people making bad management decisions? Well, it seems to me that the cause would be bad management leaving the decisions up to them.
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.
Oh, you understand that all the technical failures were failures of management to evaluate risk, hire competent people, manage time, define the project, or other basic management errors. Well, I guess when management forces technical people with no real managerial training or experience to make managerial training, it is all the fault of the technical person. Yes, it is easier for the manager to just defer the decision to the people below them, but that doesn't mean that the problem is then caused by the technical people.
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.
And I think it is anyone (even non-technical people) that manage to surround themselves with a few exceptional technical people to help them with the tech stuff so they can work on their job of managing. I used to laugh at "project managers." It is a made up title for a position that does nothing. But then, I worked enough places where a manager is not capable of actually managing the resources at their disposal. Project managers exist because so many managers are incompetent.
Learn to love Alaska
Back at Rockwell-Collins, there was this one project that I was on for which the history of it was... well, lets just say that they didn't like to talk about it much. Apparently, one engineer had worked on the project for something like a year and a half before they realized that he hadn't been doing anything when at work, had been forging his progress reports, and all he had to show for the project was an animation of a dancing frog.
We also have a halon fire extinguisher. Its always nice to have a fire extinguisher that kills people around.
But isn't this, too, lack of leadership? On the government (client/customer) side?
.sig? No.
In other project news, 2 + 2 = 4. No it's 5. No it's 8, No it's 23...
Did he inhale?
I'm speaking here as a retired systems architect with experience in large US Government projects. Note, Barry Boehm and Fred Brooks seem to have similar opinions
These projects are typically massive, well beyond the ability of a single person to comprehend, and their requirements have significant volatility, particularly as technology evolves. Experience shows that the initial design is almost never feasible and never efficient, so significant rework is unavoidable. At the same time, the specified development processes are heavyweight with massive tomes of formal requirements, which makes rework extremely expensive. Organizations that can handle that mixture of problems are vanishingly rare.
One of my current interests is coming up with approaches to scaling up agile methods to address large systems. Based on my experience, I think it can be done, but we don't yet understand how.
I have been part of several government projects that worked, and have seen several that didn't.
/recognise/ anything creative. All they recognise are big names ("You never get fired for buying Microsoft, IBM, Novell,..."). All they talk about is which big company they signed a contract with to take over their agency's IT administration.
The projects that worked were started BY techies, sometimes even behind management's back. In one case, it produced a system that rivals commercial products costing tens of millions of dollars. All started by one person, and finished off by two or three others, straight out of university. These systems worked. They are deployed today in production, and are gaining international recognition. They were creative, done by talented staff who understood the agency's business, and who understood computers and programming.
The projects that didn't work began with corrupt sweetheart deals, or with non-techies asking external consultants to do their thinking for them. The consultants simply built what they were asked to do, without any real creativity, without any real understanding of the business (unlike us staff programmers). Sometimes they just pushed something through, so that they could be seen to do something. They would retire before the project was recognised to be an expensive, time-consuming failure.
So many government IT managers are simply contract administrators, not computer professionals. They cannot do anything creative, and (worse still) they cannot even
Not all managers in the government sector are mediocre, uncreative types. But way too many are.
I am anarch of all I survey.
As someone working to develop a system that will be used by the UK government, I can tell you that statement is very true. Not only that, they often don't actually know what they want. They'll give you a vague specification and they'll tell you they want features X, Y and Z, but when you hand over the completed system, they turn round and say they didn't ask for that, they wanted something different.
We have the same problem in the UK, and I expect it is the same everywhere. I have worked on good projects backed by government money, but the problems seem to arise when the government is the provider of the detailed requirements. I think this is because the government can only provide top level requirements, and the detail should be fleshed out by experienced requirements analysts. Unfortunately, government organisations do not consist of high achievers who have made their way to the top through good decisions. Government organisations consist of people who have made their way to the top by cautiously waiting long enough, and their natural instinct is to avoid tough decisions. Of course, tough trade-offs have to be faced and dealt with to reach a coherent set of requirements. Any project with the government will not be able to do this without a lot of futile hand wringing and back tracking. Coupled with all that is the fact that government people have an innate belief that they, not the technologists, are in control. They believe they can realise change faster that the technologists can provide it. Technology development has a pace that technologists understand, while government people have different objectives that may be changed in a hurry as public opinion sways this way and that.
I stole this
It's a very bad situation when management don't listen to their staff on issues of costing. Management can either pick a date and let the techies choose the features, or they choose the features and let techies set a date.
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 zero software development experience.
Linux is not Windows
Over here in the UK all the big IT projects are outsourced to large consultancies and they are all a distaster for 4 basic reasons:
#1: They don't know what they are doing. Anybody who does know what they are doing and fights passionately to save projects turning to junk is labelled a troublemaker and does not progress. Arselickers and inoffensive people with nice hair abound the management and they haven't got a clue.
#2: Lack of bottomless pit of money. When you don't know what you are doing how can you expect to guess corrently at the cost? This is only really a problem for cash strapped places like the govt. When these companies feck up in an investment bank they can just continue to extract cash till the entire project gets cancelled
#3: The useless twats that basically caused the disaster aren't fired and publicly humilliated
#4: The 'old boy' network. These huge companies continue to get the contracts even after strings of disasters because everybody is in bed together. For example, up until 1997 Arthur Anderson was banned from doing govt work after the DeLorian scandal in the 1980s. But in 1997 when new labour won power this was reversed. Surprisingly one of our cabinet ministers, Patrica Hewitt was Director of Research at Anderson Consulting.
when I was working for a bank on a small internet banking project, a well known consulting company managed to stuff SIX HUNDRED people on it, with plans to raise that to a thousand. I think there were perhaps 25 people who wrote code there. And none of them knew anything, they were straight out of college and went on a week's intensive course on the application platform. and were being billed out at over £1500/day. I as a contractor was not billing out at £1500/day and had to baby sit them.
until we can stop these big consultancies getting the contracts or until they reform themselves into knowing what they are doing or until we can break the old boy network we will continue to chow down on stories of total abject failure safe in the knowledge that the perps have not been thrown out on their ear, they still have their nice house, BMW and golf club membership...
righto thats it. now back to planning my own world dominating business, Knackerator Consulting. I think the time is right for me I don't like coding anymore and couldn't give a flying fuck about delivering a project on time or budget. Anybody with me?
But was the dancing frog properly documented?
Watch this Heartland Institute video
Why your project will fail:
1. Use of an inappropriate methodology.
2. Lack of customer involvement.
3. Lack of formal project management practices.
4. Dissimilarity to previous projects
5. Project complexity
6. Requirements volatility.
Is Your Development Project a Sinking Ship?
The one-minute risk assessment tool
If you know any politician who can limit his damage to an animation of a dancing frog, go vote for him.
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.
Watch this Heartland Institute video
Most large IT projects fail.
So, the simple idea is - do not have large IT projects!
Always start small and grow. Things will be a little more disjointed, but at least you will have a system that does something. The alternative is millions of dollars down the whole and years of peoples lives gone for nothing whatsoever.
It's better to integrate disparate projects than to bury dead giants.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If you find your government doing something stupid or corrupt, does Hanlon's Razor mean that you should ignore it?
If you find yourself doing something self-defeating, does Hanlon's Razor mean that you should take no action?
> Why are the technical people making bad management
> decisions? Well, it seems to me that the cause
> would be bad management leaving the decisions up
> to them.
Absolutely.
The grandparent post was along the lines of "management should leave decision making to the technical people"; my post tried to highlight the dangers of doing this.
It's not as simple as management=bad, non-management=good; you need competent people doing these roles, and you find competency in both management and non-management staff.
> Well, I guess when management forces technical
> people with no real managerial training or
> experience to make managerial training, it is
> all the fault of the technical person.
In *all* of the cases above, the problems were caused by technical people assuming too much authority off their own bat. It wasn't a case of management roles being forced onto these people; more a case of these people attempting to make decisions without understanding the consequences.
As above, these are management decisions that need to be made by *someone*; either they can be made by managers or non-managers, but in either case it's easy to get them wrong if you don't do your analysis and risk assessment properly.
In the Netherlands government is implementing a general communicationsystem for emergency-services called C2000.
Idea behind this is that all services can communicate with each other without using like 20 different systems. The project started around beginning of the 90's based on technology of that time. Now the project is almost finished, technology inside these 'portophones' can be almost called obsolete. The most basic cellphone cuurently sold in stores has more advanced technology inside. Way to go !
The government project I work on has some hidden corruption.
The company that wrote the software was simply not interested in delivering the perfect product as
now they are getting money for support and fixes.
They simply have the backing of a few influential government officials - the reason why they were chosen in the first place and why now they are sucking taxpayers money...
"Amount of resources and time allotted are both directly related to leadership."
Sometimes resources available and the required deliverables are limited by external factors and about all the management can do is rearrange the deckchairs a bit rather than properly plan the project. Perhaps then the correct decision on the part of the management is to tell those at the higher level that the project cannot be achieved, but this can be a career limiting move.
Failing to deliver the project can also be a career limiting move but at the point of planning the project is not certain to fail so the manager's career is not certain to be damaged unless or until it does fail, which might be 5 years hence.
I suppose this is just a failure of the leadership at a higher level but sometimes the project management has an impossible task to achieve.
Tenure.
Not that I'm complaining, I work in France.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
One thing I regularly see is "I want this" because that's what they heard elsewhere. Whether its a product, a specific technology, or something else, new technology marketing promises about as much as new cars promise a new and improved you. Its the job of the techies (managers and code gnomes) to not only manage scope of the project, but question the business use behind this. What is this really going to do? How will it really help? This takes some real honesty and character from the project participants--- many people are unwilling to simply say "I don't know", that's what kills projects. IT projects succeed when there is a clear business goal defined and scope of that is managed. Then, extra bells and whistles are just that. When there is no clear business goal, its best to use a more agile method of "try this little concept, evaluate, decide direction".
It is not a failure that is unique to government.
In the UK most big IT projects are in any case outsourced to one of the big IT firms rather than being done in house, yet often these projects still fail to deliver. Also other companies have also outsourced IT projects (Sainsbury's new stock control system springs to mind) with sometimes very poor results. Even with Microsoft we see Longhorn being delayed, and with features removed. So there is nothing unique to government projects here.
First, the people working in government are usually not the brightest candles in the world. In government people are promoted almost entirely on seniority and not on skill or intellect. Thus the bright ones leave for greener pastures leaving behind a bunch of idiots. This can be seen in California where Oracle forced the buyers for the state to buy licenses for EVERY state employee, even janitors who never touched computers!
Second, the worst contractor gets the bid. Either as a pork favor for a friend in government or from being the lowest bidder. Neither of these is a good approach for picking the bidder most likely to succeed. This can be seen in nearly every other IT project the government has attempted to undertake.
If someone says he and his monkey have nothing to hide, they almost certainly do.
Not unique to government, but the difference is that a for-profit company that drops the ball too many times will lose money and/or customers. Governments have 100% market share and rarely go bankrupt.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
From personal experience, I can tell you that leadership is not the only issue.
... the same system.
Take the massive boondoggle that was the Air Traffic Control revamp in the 90s, which IBM eventually defaulted on. The problem was not with IBM, nor with the leadership of the project. The problem was in the specification. The project was to replace an aging and broken ATC system with
The specification was an excruciating description of the existing system, right down to the shape of the displays. IBM was actually forced, at one point, to provide circular masks for the displays so that they would look like the old scopes on which controlers would manage traffic. That example might be humerous in retrospect, but it demonstrates the deeply entrenched fear of replacing the old system, and how it crippled any attempt to actually do so.
What SHOULD have been done, and what often DOES work in corporate and government settings is to create a small, well-defined pilot program to replace pieces of the environment. One controler could have been set up on a new display that took data from the old system. One new radar tracking system could be installed in an airport with a system in place that allowed the old displays to use it. At each stage, incremental progress could be made, and the ultimate goal of removing the need to ever resort to little paper-and-tape airplanes on displays when the system went down could be achived.
I suspect that the FBI went the same way. An attempt to replace their entire case-management system was likely too large, and not modularly speced. This, of course, results in several problems. First off, you can't observe early that a single piece is not going well, fire the contractor and re-bid that part without impacting the whole project. You also cannot re-plan parts that appear to be unweildy without having to freeze the spec for the entire project.
Project management is a lot like programming. Keep it modular, keep it simple, make sure it works at every stage. The same rules apply. The same solutions work.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
"As someone working to develop a system that will be used by the UK government"
If they do use your system, it'll be a first for UK government IT...
This is not in any way specific to government contracts. Private clients do the same thing all the time, and if it's a big customer, management is just as reluctant to put down their foot.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
I bet you're currently in the trenches and have never been in upper management...
Wrong! I expected a response such as yours. I have been in BOTH areas. You are mistaken about most of your opionions and need to do a reality check.
Add UK government to the list. The passport office computer system, national air traffic control system and the list goes on.....
It's funny you should say that. We had a contract for a trial usage period with a certain group that lasted most of December. When they came to use the system in January (having not touched it the whole time in December), they were agast that they didn't have access.
The more I see the inner workings of my government, the more I despair.
Let me add this, if your were REALLY a good manager, you would publicly give full credit to the two most important members of any roll-out, the users and the people on the front-lines. The fact that you ignore that fact in your response, tells me that you are not really a good manager.
Of course any project needs an excellent plan, but plans can be developed by others besides leaders and managers.
I am not saying that managers are useless, because I know better. As I said, I have been a manager too.
And they modded me as a troll. LOL.
The parent post is not off-topic. Stop sucking on your colon polyps and try actually reading these things.
Many projects fail because results are not produced fast enough. When it begins to spin its wheels people become demoralized. Its because many people are so results oriented. Success (even short term) breeds success. So to fix it put a smaller group of people on it who get results quickly and gradually add onto a successful core.
I can't say you're wrong but there is something more to be said. One very big problem lies outside of company. It's the customer himself. How customer chooses IT company? He's looking for the fastest and the cheapest offer. The result is pretty obvius - the companies (especially when financially under pressure) declare totally unrealistic times and costs. Only mass products for opened market are free from this shortcoming. Customer doesn't have the konowledge necessary to estimate the time and costs of the project. Once he has invested a lot of money he is eager to add some more to get the final product finished. Of course this is dishonest approach but this is very common. And again it's up to the leaders to decide: to let their company go down or to cheat like all others do. But from this perspective their choice doesn't look that simple anymore.
Do you mind if I steal this line? 'cos it's brilliant :-)
Read my blog.
As someone who has worked in or for the govenment for my whole career, project failures can be tied directly to leadership. The following are the primary reasons they fail: 1. Failure to define the problem. 2. Does what you're doing/proposing solve #1? Most times the answer is no. 3. Failure to fully document the scope of the project. 4. Failure to stay within the scope of the project. 5. Failure caused by not enforcing standards or processes. 6. Asuming that the latest and greatest technology, methodology or fad will be the solution to everything or conversly, ramining wedded to the old way of doing things. "That's the way we've always done things." "We can't solve problems by using the same kind of thinking we used when we created them" --Albert Einstein
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.
You are either someone who has never worked for the government, or work for a branch that doesn't have issues.
In my last employment working for municipal government, I have never seen such a poorly run, mismanaged, fearful bunch. It's amazing that anything got repaired in that group, much less new implementations. You have to run every idea/change through 5 different people, 4 of whom have no idea what you do or are trying to do, but still have the power to block it. Don't even get me started on trying to purchase hardware.
Government also seems to be the last bastion of hope for employment for most people, and once they're in, they're in to stay.
Keep in mind I'm not a cynic. I'm actually a realist/optimist. I had great faith for our government. But seeing that is run by people/processes that have no right making decisions, I'm very disappointed.
There's around 40,000+ unemployed contractors who share the same opinion at "shout99.com"
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.
-----------
I am a developer and managment has tried repeatedly to make me take management responsibility. I simply refuse to the point of "I'll leave if you make me do this".
You can't manage projects, people, group cooperation etc. and write the software too. Management and writing software need to be done by different people. Otherwise the software will never get finished. It's 2 jobs with competing goals so two different people need to do it.
This may get blurred if you run your own company, or work in a small shop. But when you need to manage cooperation among 5 departments and 20-30 people in those departments, that's all you can possibly do. You cannot possibly write good coherent code if you have to answer the phone or call a different person every 5 minutes, and go to meetings for half the day.
At my last job, I did the "Yes sir" thing and did all of this stuff. Guess what, nothing ever got done. Guess who took the hit for the projects not getting done on the deadline? The developer, me.
Not the sales guy, the "project manager" or my manager, me... I refuse to let it happen again.
l8,
AC
I absolutely agree that is happening. However, if the leaders of government know they have been burned on the last 10 projects, they need to change the way things are done.
I did not intend to sound personally adversarial. As I said above, if the government gets burned 10 times with big software projects, government leaders must change the way they do things, or not do them.
This kind of thing can be explained, but not explained away.
Large, complex projects won by the lowest bidder are doomed from the start.
Just last night [well, in the wee hours of the morning today], I was surfing Travelocity and Expedia to make some airline reservations for a trip out to the left coast.
At Travelocity, I was hooked up with flights that involved two diffent carriers, and when I went to check-out, I was given schematics of each jet so that I could request my seat preferences. And of course after I enter my credit card number, everything ties into the VISA/Master Card/Discover/Amex credit card backbone, which in turn ties into the inter-bank secure backbone...
The mere thought of the IT infrastructure and inter-systems communications necessary to get something like that up and running is just staggering. And yet the private sector proves that these sorts of things can be made to work, and work pretty darned effectively.
So as tedious as some of these "big" problems are, they can be solved.
But I agree with you: There is a huge [maybe even infinite] amount of inertia in the bureaucracy directed at avoiding any possible risk and preserving the status quo at all costs.
The grandparent post was along the lines of "management should leave decision making to the technical people"; my post tried to highlight the dangers of doing this.
And I read that post as "management should leave the technical decisions to the technical people." Which is still wrong, but not for the reasons you cite. Very few business problems are technical. The technical side of technical solutions is smaller than the other parts of the solution. Having worked as a manager and a project manager, but now working back as a techie (and liking it much better than managing), I continually have to prove my managerial skill to the higher ups before they leave any non-technical decisions to me. I even outline the business case for technical decisions (and have to reel in the sales staff, who, without technical training, makes all sorts of technical decisions in order to please customers - why can't they just promise results, rather than promise results and outline the technical solution to achieve the results?).
The simple reason for not leaving decisions up to techies is that the technically best solution is rarely the best business decision (for projects of sufficient size).
Learn to love Alaska
of a small bureau - this is funny because it is true. Most of the CIOs I met were old school engineers, and many of them were actually originally CFO/accounting types. Because that was the first group in government to use computers, they often became the CIOs. Which was bad because they did not know the tech.
And because government lacks the biggest metric of the private sector - profit - there are few useful measures of success in government projects.
I agree completely. Government, in my experience, is particularly change-adverse. The more sudden and large the change, the more push-back you get. By breaking the changes down to palatable SMALL pieces, and an implementation that doesn't impact existing systems except where absolutely necessary, you can implement the system before anyone realized that it's actually a CHANGE, not an ENHANCEMENT.
Grandiose projects are pretty much doomed to failure from the beginning, unless they can be granularized down to decoupled, independent activities/projects.
... really, it does, and you are wrong. I would love to see you come into my office, with no degree in structural engineering, and design a 50 story moment-frame building that can resist an earthquake. Your probability of finding anyone who could do this without a degree is so close to zero (I do not know anyone offhand who can do this). There may be some fields where you are correct, but they do not include structural engineering. Absolutes are danagerous.
----- There are two kinds of people in this world, my friend; those with loaded guns, and those who dig.
Thanks for that insight on this project. You clearly are not that slow!
rd
The market simply will not bear the cost, in money or time, for software to be Done Right. For any given project, at least one of your competitors will over-promise the result for cheap, on a death-march schedule. This means you (as a company) must follow suit, or nobody buys your software.
Also, often a software company is somewhere back in the chain of contractors. If a PHVP at FooCorp says the project must be finished in 18 months, that means that Vendor A must be finished in 12 months, and so Vendor A's vendor B must be finished in 6 months. If you are vendor B, if you tell vendor A that to get it done well will either cost more or take 9 months, you'll just be rejected (A's price they can pay, and their schedule, are out of their hands).
The way w.e. do software projects is probably the most backward, inefficient in the world. It's unique in that programmers are hired to do very specific tasks and are sent packing when they're done. Each role is filled by people specifically for that one function with no-one responsible for overall success. Even the representatives for these projects are only contracted to be representative for a year and then they're gone.
At the risk of beating a dead horse...
I don't disagree that the leadership can (and should) be blamed for all these problems.
However...
I think that you're just pointing out who to blame rather than how to fix the problems. There are issues around
* resource management (How do you get enough resources? How do you estimate how many resources you need?)
* methodology (waterfall development, iterative, agile?)
* project management (effective milestones, tracking, allocating resources)
*customer management (requirements, probing for real needs)
* software architecture (technology, platforms, 3-tier, 2 tier, etc.)
Each of these areas have different potential pitfalls and different ways to avoid them. To simply classify them all as just "leadership problems" means that you never get closer to understanding why the problems occur or how to prevent them.
-Peter
Even though this is from an AC, I'll reply anyway just for the hell of it.
I never discredited the people on the front lines in any way. I kept saying to take care of them. I have a programmer I want to hire, but haven't been able to due to funding issues. I've kept him in the loop on projects and have given updates to him on a normal basis. When he's too busy to talk, I respect that and let him do what he needs. I'm more of a relationship type of person and thats how my business runs.
This may be a cliche, but my business honestly works as a family. All my employees are very open with me and have NO problem telling me how it is when I have something wrong. When they can show me that I'm wrong, I have no reason to implement what they're saying and admit to the issue.
While customers can be a pain, no business would be in operation without them, so I figured this would be an issue I wouldn't even need to touch on.
Like I said before, the people in the trenches must be kept happy. Part of keeping them happy is telling them they're doing a good job, sharing info, keeping an open door policy and honestly sticking to it. One other thing my employees like the company is because I've specifically told them and our customers that I will not outsource any part of our business.
Even though this is from a "manager", I will respond. I am just joking for the most part, but you started it with the AC comment.
I respect your attitude and methods in running your business, but I still think your are missing the point. In order to be a really GOOD manager, you should not see yourself in a different light from a customer, user or front-line worker. You need to completely understand all three situations and be experienced in how to make them all work together. Anyway, it sounds as if you are doing ok, so carry on...
BTW, some AC's are not what you think.
As I remeber it, another Al (Capone) said something the same. But I'm perhaps getting too old to remember clearly. Just a thought ..... I think there's a song too !
How many beans make five, anyhow ?
-project itself is much larger in scope than the original idea of Torvald's.
+project itself is much larger in scope than the original idea of Torvalds'.
I'm going to go out on a limb here and guess that you're not in a leadership role in large IT projects.
content management for designers
I've had a leadership role in many smallish to mediumish projects
In one of the projects I worked on as both an official and unofficial lead for various pieces we turned 4 NT 4.0 domains and a related Exchange 5.5 infrastructure into a a single ADS domain spanning 6 sites with Exchange 2000 on 4 of them. It included 3 front-end infrastructures and two Exchange clusters by the time all was said and done. 5 states and a foreign contry almost exactly on the other side of the world were involved as well as a Netware eDirectory tree that had to be almost completely restructured to allow for full sync with ADS.
The technical stuff, though certainly not trivial, was definately not the hardest part. Coordinating with several layers of management, the Netware guy, peers at 3 of the US sites and the IT guy on the other side of the world who spoke broken english, on the other hand, was very difficult. That's not even counting 700 users that had to change the way they logged in and a full IT staff that had to learn not only the migration procedure but completely new procedures for almost everything they had done in the past.
Leadership was why this project almost failed at one point and why it ultimately succeeded. I've seen other projects fail and leadership, or lack thereof, was always the issue.
The tech stuff can can always be worked out, but on big projects it cant be worked out by one guy in a room. When you get more than a couple of folks that need to work on a project, all of a sudden leadership trumps everything. Even if all the leader does is allows for an atmosphere where bright people can work togther and come up with solutions, that's far more than many leaders do. On governmental-sized projects though, the layers of leadership will have to do far more than that.
Blaming it on the guys in the trenchs, or the software, or the hardware or anything else is like blaming the failure of your shipping company on bad trucks and drivers. Didn't you buy and hire all of them yourself?
TW
Project managers exist because so many managers are incompetent.
At MyCorp project managers are way overworked.
Lessee, that would mean that our managers are...
"Provided by the management for your protection."