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."

Comments

Leadership is most important on large IT projects.

[Total_Wimp]

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.

I concur

[countach]

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.

Re:I concur

[Evil Pete]

I put the blame partly on managers in charge of the project that are too non-technical and distant from the nuts and bolts of what is going on.

Another factor is that the complexity of some of these projects is non-linear with respect to the 'size' (as say measured in the number of requirements). Government project managers should have a new mantra, something like "Small is achievable". The old 'divide-and-conquer' strategy, one of the first things you learn in programming. Break up the problem into achievable units and then use those to construct the solution. Sometimes the bleeding obvious is the first thing forgotten. Man, I'm just full of cliches today.

Re:I concur

[crimoid]

How much did the original system suck 20 years ago when it was first tuned on? Did IT love it then? Would the original system still be supportable 20 years from now?

My point is that from time to time groups are asked (if not on purpose) to eat dog food for a few years. While it may be true that your new system might be a steaming pile that is destined for the trash bin it may also be equally true that the new system is a few steps toward a flexible, modern system that will carry your organization through another 20 years.

You say that you are likely 3 years and a little pain away from accomplishing your goals. Thats 9 years of development and deployment for potentially another 20 years of use? Almost 30 years of mileage out of one project? In some circles that is a huge accomplishment.

Re:I concur

[ebyrob]

I know how much code is "hard work" and how much code is "slacking off".

That's naive, even for a "code like hell" mentality.

So, uh, I suppose you'd fire the guy who wrote qsort, or bit-torrent, or the tiny decss descrambler because they didn't turn in enough lines of code in a day? Heck, I've gone whole weeks where the number of lines of code in my CVS checkins were NEGATIVE (ie: added-removed). Not positive, not zero, but less than zero. Why? Because the guy that came before me was a sloppy hurrywort (or was being overly pressured by management to hack something out quickly) and I took the time to clean up the mess...

Features, requirements, stability, performance deadlines. These things matter. Lines of code? Everyone solves problems differently. Some of the best programmers write extremely small code. Then again, some don't. If you're going to be a technical watchdog, at least be technical about it. (Also remember, there's a good reason managers don't breathe down their engineers necks like they were two year olds... It's degrading, demoralizing, and likely to lose you the kind of self-motivated people you'd like to have around.)

Re:I concur

[danielrose]

Because we have about 10 layers of screen scraper type things, which is not fun. One gets the info from the terminal session on a HP-UX box (actually I think its a largish cluster of boxes), writes it out to files on a network drive, which get imported into a datawarehouse which gets pulled into some access database at seemingly random intervals, and back again through a similar process!
Weeee! It's also fun when the datawarehouse is around the other side of the world and it goes down..
Its not an enjoyable system, and I hear we are STILL looking at peoplesoft (should be a fun move considering the future of it looks rather bleak)

Re:I concur

[Fulcrum of Evil]

Because we have about 10 layers of screen scraper type things, which is not fun.

It's not fun, but at least it works (in the scenario I responded to). I don't know your situation, but the other one looked like a political move more than anything.

Re:I concur

[demachina]

Heh. Post on slashdot and ask why IT projects fail and surprise, surprise all the geeks blame it on the managers, venting angst they still feel from some recent IT project that was a disaster and they blame on their manager.

Big government IT projects, and government contracts in general, fail because there is zero reason for them to succeed, they are designed to fail. Big companies who live to drain tax dollars out of the government, like Lockheed, CSC or ESD can fail on project after project and they will still have a thouroughly good chance of winning new ones. The government rarely withholds payment even if the project craters. So if the government never punishes failure why would contractors care if the succeed or fail. The worst that will happen is a little bad press, they wont get the next contract for the department they just cratered but there are always plenty more. After CSC botches it, ESD gets it, they botch and then they will try CSC again etc. Same thing for Boeing and Lockheed. Thanks to merger mania in the 90's there are only two aerospace giants left and its not much different for every other big government contracting sector. The government has to pick one or the other of the big players no matter if they've cratered on contract after contract.

You really need to understand how these companies are structured. They are well oiled machines for identifying opportunities, submitting impressive proposals, using undo influence and landing contracts. They put their best people on winning contracts. Once they win it its another story. Then they are just putting warm bodies in there to fill slots and bill hours as they march through milestones.

The irony is a contractor will probably make more money if the project goes bad. If the project goes bad their contract will be extended year after year. The civil servants will just throw more money at the project in the hope that if they just put in a little more they will turn the corner and pull it through.

If the project comes in on time and on budget the contractor will make less on it than if it goes bad and overruns, so why should come in on time and on budget.

Consider Lockheed's F-22 as described in the link above. In some respects it an impressive fighter but at $300 million a copy it ridiculously expensive. It was supposed to be operational a decade ago but the government just keeps pouring more and more money in to though the U.S. already completely dominates every other Air Force on the planet with the much cheaper planes it already has. Lockheed can continue to develop it for another 20 years and may never field an operational squadron. They were punished for their failure with another $200 billion contract for the Joint Strike Fighter. They were just given a contract to build 5 or 6 Presidential helicopers for $1.5 billion dollars. Thats $300 million each for a helicopter.

Why does the government do it. Simple, the government/contractor system has devolved in to massively corrupt system. There is a giant revolving door between government, the military and these big contractors. The ambitious and greedy are only taking government and civil service jobs so they can establish connections and influence, do favors for big companies, retire from government and cash in a massive way with executive positions at those same contractors. Any Air Force general whose ever steered contracts to Boeing or Lockheed has a gold plated job waiting when they retire, where they can continue to influence contracts pulling strings with people who use to be below them in the chain of command.

Darlene Druyan is another classic example. She was one of the Air Forces' top civil servants for procurement. She steered a ridiculously lucrative contract to Boeing for 767 tankers, and before the ink is dry she gets a lucrative senior executive position at Boeing. Only catch is it was so blatant that Congress said enough is enough and damended the

Standard problem with all outsourcing

[originalhack]

The government doesn't generally have programmers familier with exactly how they really work. So, they outsource to big software companies. Instead of rapidly creating a prototype and trying it out and making sure they are on the right track, they create a massive project and find out way too late that they did not ask for exactly what they needed.

Businesses trying to outsource their business application development also learn this the hard way. If your programmers are not intimately familier with how you operate, it doesn't matter how smart they are. Also, if you are trying to create a new way of operating, try experiments first.

Re:Standard problem with all outsourcing

[Etcetera]

Instead of rapidly creating a prototype and trying it out and making sure they are on the right track, they create a massive project and find out way too late that they did not ask for exactly what they needed.

Sounds like the Feds need some Perl Hackers :)

Also, Wired News reported this story too...

[antdude]

Click here.

Our state Department of Transportation...

[mosel-saar-ruwer]

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.

"Kaizen", the Japanese art of improvement

[Dancin_Santa]

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.

Re:"Kaizen", the Japanese art of improvement

[timeOday]

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.

It's true that small projects are never huge failures (by definition). The problem with incrementalism is that eventually you wind up with a big hairball where trying to fix one thing breaks three other things.

underqualified people in charge

[trolluscressida]

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.

Need to tell them what you want

[mboverload]

Many projects I work on managers tell us almost nothing about what they want. With the descriptions they give it could be a game that involves you moving packages from one rabbit to another.

It's not the grunts, its the managers who have no idea what they are doings, and we wonder what the hell they are doing in IT.

It's not necessarily the managers...

[DelawareBoy]

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.

They are trying to make all the solutions work...

[JoeCommodore]

They are trying to make all the solutions work in one fail swoop. When you build a comprehensive system to do it all from the get go expect comprehensive problems.

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.

They aren't really failures.

[Futurepower(R)]

'Failures are very common, and they've been common for a long time.'

They aren't really failures. They are deliberate government corruption. Anything that has been "common for a long time", with no effective corrective action, is deliberate.

The IT corruption is small compared to the military procurement corruption, where the dishonesty can be kept more secret. The U.S. government is the world leader in buying equipment to kill people and destroy their property. (The least socially skilled way of relating to other people is killing them.)

U.S. citizens, it's 7 PM. Do you know what your government is doing? Unfortunately, you don't.

Re:FP

[Anonymous Coward]

This is totally not a troll or a flamebait.

The only thing our 21st century republic does efficiently is 1) raising "revenue" via taxes, and 2) removing liberties from the masses. Disagree, don't mod...post!!!

Scope!

[steve_vmwx]

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.

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 :) 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.

Re:Corporations too.

[That's Unpossible!]

The summary ignores that corporations are just as bad, but that corporations don't admit their problems.

Public corporations sure DO admit their problems. Then their stock takes a pummeling, people in charge of the failures might be fired, there's accountability for the failure in some way in almost all cases.

Now compare that to the government. If the blunder is serious enough, someone might be fired. But then they are right back asking for more money of my money to flush down the drain.

One major factor driving massive failure...

[TheOriginalRevdoc]

...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.

Mismanagement

[OverflowingBitBucket]

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.

Re: Depends on what you call a leadership problem

[phamlen]

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

Re:Corporations too.

[mc6809e]

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.

This just isn't true. Corporations usually do admit their problems. They often have a legal obligation to inform shareholders about why their company lost $$$ dollars.

And besides, the Fed can afford to fess up. What's it going to cost them? If anything they'll get MORE money claiming they didn't have enough in the first place to make the project a success. Failure is almost always used to justify more spending. More money is the award for failure.

And it's not like the government is going to go out of business but companies that chronically screw-up will and people will lose their jobs.

Seems to me companies have a much greater incentive to make sure projects succeed.

Re:Not really

[TykeClone]

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).

I don't disagree - but using a false degree to obtain a job is fraud and does say something about the character of the holder.

Re: Depends on what you call a leadership problem

[Total_Wimp]

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?

Re:Not really

[jcr]

A degree means nothing---absolutely nothing---in determining whether someone can do a job.

I agree, but a fake degree points to a lack of character, IMHO. If I discovered that any candidate for a job had presented me with a bogus degree, I'd conclude from that that the person in question was a poseur, and not qualified for any job but politics.

-jcr

Re:Management? Not always...

[darnok]

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.

Re:Leadership is most important on large IT projec

[WebCrapper]

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.

Re:Learn a lesson from a success story

[demachina]

Is this the same IBM who just sold their PC business to a Chinese company. The government is currently scrambling to evaluate the security implication of letting a Chinese company deliver personal computers to a bunch of government and military contracts IBM has already landed. Not sure it really gives them great street cred as a pillar of trustworthiness in government contracting.

Not sure you you can really cite any of big supercomputers as really illustrative of how a company will perform on a big and complex IT project. Company after company has delivered these bragging rights supercomputers, year after year and there aren't a lot of failures. Once you come up with a memory sharing scheme and an OS that will stay afloat across a lot of CPU's its not like there is really a lot of complex software to develop. Its mostly an exercise in logistics and trying to get the thing up and running before the CPU's in it are obsolete. You will notice that the government keeps buying these things over and over, because at the rate CPU's are advancing they tend to be obsolete before all the nodes are powered up. I wonder whats happened to the predecessors of these that were bought 5 and 10 years ago. A lot of hazardous scrap to recycle.

Re:Management? Not always...

[AK Marc]

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.

Re:Leadership is most important on large IT projec

[Darren Winsper]

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.

You can't have Leadership in the Dilbert Zone...

[Tangurena]

Having worked at some places where "ERP" or "CRM" was to be "implemented," the real issues are indeed the fault of the people at the top. There is a large disconnect between the way that folks think that their company is run, they way they say it is run, and the way it really is run. In a perfect world, all 3 would be the same. Alas, I live on Planet Earth. Neither companies nor governments have the monopoly on corruption.

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.