Forgot your password?
typodupeerror
Businesses IT

Anatomy of a Runaway Project 326

Posted by kdawson
from the off-the-tracks-and-ploughing-up-dirt dept.
JCWDenton recommends a piece by Bruce Webster revealing some insights into a failed multi-million-dollar IT project. "The following document is the actual text — carefully redacted — of a memo I wrote some time back after performing an IT project review; names and identifying concepts have been changed to preserve confidentiality (and protect the guilty). The project in question was a major IT re-engineering effort for a mission-critical system; at the time I did this review, the project had been going on for several years and had cost millions of dollars; it would eventually be canceled and the work products abandoned. The memo itself provides an interesting glimpse into just how a major IT project can go so far off the tracks that nothing useful is ever delivered."
This discussion has been archived. No new comments can be posted.

Anatomy of a Runaway Project

Comments Filter:
  • Text of Article (Score:4, Informative)

    by gammygator (820041) on Tuesday June 17, 2008 @01:54PM (#23826709)
    The site is acting like it is soon to be slashdotted...

    Anatomy of a runaway IT project

    By bfwebster on Jun 16, 2008 in Main, Management, Project Failure

    [Welcome to reddit and FARK visitors!]

    The following document is the actual text -- carefully redacted -- of a memo I wrote some time back [i.e., several years ago] after performing an IT project review; names and identifying concepts have been changed to preserve confidentiality (and protect the guilty). The project in question was a major IT re-engineering effort for a mission-critical system; at the time I did this review, the project had been going on for several years and had cost millions of dollars; it would eventually be canceled and the work products abandoned. The memo itself provides an interesting glimpse into just how a major IT project can go so far off the tracks that nothing useful is ever delivered.

    Note that the "ABC" consultants were a small part of the overall project team and had been brought in relatively late by "BigFirm" in an attempt to get the "FUBAR" project into production; they neither initiated nor managed the project. [NOTE for those of you who have written or done Google searches: "Bob Winsom", like all the other names in the memo as transcribed below, is a pseudonym.]

    CONFIDENTIAL MEMORANDUM -- EYES ONLY

    Over the past two weeks, I've conducted confidential off-site group interviews with all of the ABC consultants working on the FUBAR project. I did this at [ABC manager's] request, after a few of these consultants spoke privately about FUBAR with him. The feedback was consistent and raises serious doubts about whether the FUBAR project, as currently pursued, can ever yield a successful production deployment.

    This report groups those comments into several broad areas. It is relatively unfiltered and extremely direct (no withholding). It represents the private comments of ABC consultants who have little to gain and possibly much to lose by being so blunt. These are not the whinings of purists picking nits. These are the grounded assessments of top-notch IT professionals who have among them a century or two of experience bringing projects to completion -- particularly those involving [specific IT] technology -- and who are down in the FUBAR trenches every day. QUALITY OF WORK AND EFFORT

    ISSUE: Several consultants said -- and the rest pretty much agreed -- that far too many of the deliverables, artifacts, and activities (e.g., algorithms, source code, system configuration, design/architecture documents, testing, defect tracking, scheduling etc.) are substantially below any acceptable professional standards and represent a profound threat to FUBAR ever going into production.

    EXAMPLES: The code base is very fragile. A lot of it is bad old code that BigFirm didn't have time to rewrite two years ago, but now is five times its original size and even worse. One consultant said he took a code listing, picked pages at random, and found problems on every page he selected. There is pervasive hard coding of what should be adjustable parameters or at least meaningfully named constants (e.g., # of [key items] hard-coded throughout with the literal value '3, a constant named 'ninety_eight'). Builds take all night. App releases don't run acceptably, if at all, in a production environment. Developers check in files that won't even compile.

    RISKS: The FUBAR project keeps being touted as a world-class development team, but it is not producing world-class, or even minimally-professional, results. This already shows up in the project delays and quality issues of the releases to date. What the team is producing will not only be very difficult to support and modify, it will in all likelihood be unusable, resulting in a complete failure of the FUBAR project. PROJECT PLANNING AND EXECUTION

    ISSUE: Project planning and execution is all to often poor or missing completely. Milestone dates, usually unrealistic if not impossible, are based on p
    • Re:Text of Article (Score:5, Interesting)

      by IamTheRealMike (537420) * <mike@plan99.net> on Tuesday June 17, 2008 @02:03PM (#23826915) Homepage
      It's sort of interesting, in a vague way, but you can read much more dire and funny stories on (the highly recommended) the daily WTF [thedailywtf.com]. My favourites would have to be the hotel reservation system from hell [thedailywtf.com], the story of VirtuDyne and the digital donkey [thedailywtf.com] and a case of the MUMPS [thedailywtf.com].
      • Re:Text of Article (Score:4, Informative)

        by bfwebster (90513) on Tuesday June 17, 2008 @03:09PM (#23828179) Homepage
        I also strongly recommend The Daily WTF, and Alex Papadimoulis (who runs WTF) and I have linked to and commented on each other's posts.

        Also, remember that this was a professional memo written to a high-level manager at BigFirm. It wasn't written to be amusing. :-) ..bruce..
      • Re:Text of Article (Score:5, Insightful)

        by imidan (559239) on Tuesday June 17, 2008 @03:44PM (#23828727)
        The thing that bugs me about Daily WTF is that the editor often takes great liberties with the stories to make them "more interesting." You'll often find the original submitter of the story down in the comments, telling people what really happened before the hyperbole injection that each story gets before it goes up on the front page.

        I guess I should say that's what used to bug me about the site; I stopped reading it because of the lies. Look, I understand that it's supposed to be funny, but can't it be true, also? I mean, especially if it's represented as being true. And I can understand a little exaggeration, but some of the changes I've seen between the submission and the published copy are material and, really, unnecessary.

        • Re: (Score:3, Interesting)

          by jeremyp (130771)
          I'm a regular reader of TDWTF and I can't recall a single example of a gross exaggeration by Alex that has been called out by the contributor. There are often examples of misunderstandings and ambiguities that have to be corrected by the contributor, but i suspect that most of the exaggeration is done before Alex sees the story.
    • Re:Text of Article (Score:5, Interesting)

      by idontgno (624372) on Tuesday June 17, 2008 @02:06PM (#23826973) Journal

      thermocline of truth

      Damn. That's the exact phrase I've been looking for. I don't know how many times I've seen hard truths and unpleasant realities float up the organization and stop dead about 3 management levels below where someone could do something about it. Just like sonar, the people "listening" above the thermocline will never hear anything occurring below it.

      • Themocline of Truth (Score:5, Informative)

        by bfwebster (90513) on Tuesday June 17, 2008 @03:47PM (#23828751) Homepage
        If my server ever recovers, go look at this earlier post defining and discussing the "thermocline of truth" [brucefwebster.com]. ..bruce..
      • by Gary W. Longsine (124661) on Tuesday June 17, 2008 @04:09PM (#23829081) Homepage Journal
        Yes, and unfortunately, the typical bureaucracy enforces this thermocline, brutally. People get fired, not for wasting years and tens of millions of dollars through incompetence, nor for hiding the truth, nor for outright lying about the true status of a failing project, but rather more often, for attempting to fix problems by trying to go around a roadblock that is preventing the truth from going up the corporate ladder. When they are not outright fired, they are certainly blacklisted, and get to watch, as their own career stagnates, and the careers of those erecting the roadblocks advances. As a consultant, I've had the opportunity to see this happen to highly competent, dedicated, organizationally loyal people who should have been given million dollar bonuses, and promoted to Director, or CIO. It's quite sad, but I could never recommend to anyone to be the voice of reason on a project thats failing like this, unless they are prepared to lose their job.
        • Re: (Score:3, Insightful)

          by Maxo-Texas (864189)
          "you are upsetting the contractors" (moved to spreadsheets for 8 months-- then the project went in and failed-- years later management still pissed at him).

          "you wrote a program that helped us through a major catastrophe but without permission and it wasn't planned by management" (denied promotion for 3 years until the entire staff went to the new incoming manager and said this guy wasn't getting a promotion and was a single point of failure)

          You are correct. That's the blunt of it. They do not want the tru
        • by Gary W. Longsine (124661) on Tuesday June 17, 2008 @04:54PM (#23829931) Homepage Journal
          I meant to mention a slightly more hopeful thing that also sometimes happens in these situations. Senior management sometimes hires consultants to review a project like this, precisely because they suspect it really isn't going well. You talk to several folk at different levels, and they all tell you the same thing, which on the project described in the parent article would be something like, "it will fail unless several things radically change." Of course, they may represent several different visions about how to fix it, and what precisely is the problem causing the failure, though usually those overlap to some degree and are seldom mutually exclusive.

          This can happen at all levels of the organization, the truth, more or less, might be an open secret. However, for reasons of internal politics and personalities, they need someone from the outside to be the one to tell them.

          I once witnessed senior management bring in Peter Drucker [wikipedia.org], at great expense and inconvenience. Before he takes a gig like this, he basically tells the senior management that he gets unlimited access to anyone in the organization, or he's not interested. Then he starts talking to people, in private. He follows threads of interest. He doesn't spread gossip, and he doesn't make judgements, except those in the final report to his client, who is usually the CEO or Board of Directors. In conversation with people he spends almost all of his time listening. With a strategy like that, you can get to the truth of the matter, even though the truth is often very complex, from the standpoint of organizational politics, anyway.

          Later, they replaced the CIO, partly on the basis of his report, which most likely didn't say anything like, "get a new CIO" anywhere. Rather it said something like, "this project has already failed, you just haven't realized it, yet," and "here are the indicators that it has failed," etc.

          Watching that particular new CIO come in was fascinating, too. He was one of the best CIOs I've ever met. He spent about two months getting his bearings, using essentially the same techniques, only in a manner that seemed lower profile. He just visited with people at different levels of the organization, in the course of normal business, and without any apparent agenda. He didn't march in as a trumpeted turn around artist or anything like that. He was all business. Once he started making decisions, they were big decisions, and they were almost immediately recognizable as the right decisions -- or at least members of the class of possible right decisions for the given problem domain. It took a little while, but people who had been demoralized on this giant failing project (which had involved nearly the entire IT staff to greater and lesser extents) got back a sense of esprit de corps.
    • The author wasn't really involved in a FUBAR project unless he was fired for circulating "such an inflammatory memo".
    • Re: (Score:2, Interesting)

      by Anonymous Coward
      Wow.

      It's scary how much this resembles the ongoing debacle in the company I currently work for, as our "new" workflow application sucks millions of dollars into a black hole (and will continue to do so for the same reasons as the article talks about).

      Everyone who actually has to use it, hates it. None of the developers has ever talked to any of the end users. It is fundamentally broken in design (most end users are on a WAN or the internet, but it is designed to be used on a high-speed, low latency networ
    • Re: (Score:3, Interesting)

      by llefler (184847)
      There seems to be plenty of blame to go around, but I think it's rather disingenuous for consultants to be rewriting code in Java instead of [original obscure language]. The comparison has no value, and I hope they didn't bill their client for the time. Unless they were brought in to do a Java rewrite, and that doesn't appear to be the case, they should have been spending their time working in [original obscure language].

      Some of the things that stood out to me are things like "Even the current effort prob
      • Re:Text of Article (Score:5, Insightful)

        by egomaniac (105476) on Tuesday June 17, 2008 @05:00PM (#23830067) Homepage
        There seems to be plenty of blame to go around, but I think it's rather disingenuous for consultants to be rewriting code in Java instead of [original obscure language]. The comparison has no value, and I hope they didn't bill their client for the time. Unless they were brought in to do a Java rewrite, and that doesn't appear to be the case, they should have been spending their time working in [original obscure language].

        Faced with 140,000 lines of obscure cruft which barely performed an extremely simple task, they had the choice between attempting to maintain the monstrosity or start from scratch and do it right. They started from scratch and did it right, which according to the memo involved cutting out 136,000 lines of useless code and vastly increasing the performance.

        And you're calling them out on it? You think they did the wrong thing by eliminating 136,000 lines of bloat and significantly improving the performance? You're part of the reason shit like this happens.
        • Re: (Score:3, Interesting)

          by llefler (184847)
          And you're calling them out on it? You think they did the wrong thing by eliminating 136,000 lines of bloat and significantly improving the performance?

          Absolutely they were wrong to do it. First, the code they wrote did NOT lead to any production code, either in Java or it's original code base. The project was killed. Second, they weren't expected to manage the code, they were hired to HELP complete the project. Third, they were hired to modify the existing code base, not create a new one.

          The last thing
  • I view these problems as a direct result in regards to a lack of IT project managers. Even being a seasoned IT professional I wouldn't even begin to imagine the difficulties in managing a large IT project beginning to end. In my experience I have noticed in run-away projects or in slow moving projects, the problems usually are attributed to a change of project managers. I would urge any company with an IT project to do whatever they can to maintain their PMs with any incentives possible. Because the fal
    • by Ngarrang (1023425) on Tuesday June 17, 2008 @02:18PM (#23827225) Journal
      "ISSUE: There isn't enough intellectual honesty within the FUBAR project. Managers reject or explain away bad news and real problems, looking instead for people who will tell them what they want to hear. "

      This has easily been the #1 reason I have personally witnessed for project failure. I am in the process of witnessing it right now, even, with what seems like a relatively simple project. The suits and supervisors along the way are either not responding to requests for information, or change their request for features.
      • by dubl-u (51156) * <2523987012.pota@to> on Tuesday June 17, 2008 @03:22PM (#23828383)

        [Intellectual honesty] has easily been the #1 reason I have personally witnessed for project failure.
        It's amazing, isn't it? If you want to be effective in the real world, you have to pay attention the real world. We should dress that up in a lot of bullet points and start a new management fad.

        Of course, a lot of people don't really want to be effective in the real world, not as much as they want other things. They want to feel good. They want everybody to like them. They want a quiet life. They want to keep collecting their paycheck. So they stick their heads in the sand and hum the national anthem.

        Not that those are bad things to want. But you can't get them just by always picking them in the short term. Easy years require hard moments.
      • Re: (Score:3, Insightful)

        by drsmithy (35869)

        This has easily been the #1 reason I have personally witnessed for project failure. I am in the process of witnessing it right now, even, with what seems like a relatively simple project. The suits and supervisors along the way are either not responding to requests for information, or change their request for features.

        That's because if they do so, they then become potentially responsible for any fallout. Which is what's know as a "career limiting event".

        This is the beauty of moving up the management tre

    • by JaredOfEuropa (526365) on Tuesday June 17, 2008 @02:20PM (#23827255) Journal

      I view these problems as a direct result in regards to a lack of IT project managers.
      I find that there's a rather shocking lack of senior, competent technical personnel in general. On a lot of larger projects, there's not a great deal of senior devs to go around so a couple of them end up as dev lead / team lead even though their managerial skills aren't so great. There's no testers to be had so the developers end up doing the testing, and the user acceptance tests end up poorly written aand poorly facilitated. Junior developers have far too much leeway in writing code because there's not enough seniors to coach them, or even do proper code reviews. Application and infrastructure architects are too busy to give each project the attention it deserves, and as a result performance and scalability are not built into the design, and are often not even tested for before release.

      In short, a lack of senior staff means a lack of attention, coaching and oversight. If you have too many juniors, your project is going to take a lot longer to correct "newbie" mistakes, and these mistakes are caught later after they're made as well. Either allow for this extra time, or end up with crappy code.

      Sadly, the idea has taken hold with upper management that IT is simply a commodity, and as a result most IT shops have become piss-poor at identifying and nurturing talent. They expect junior developer to become "mediors" automatically after a few years, where in practice they have picked up a ton of bad habits on which they've never been corrected. And I expect the shortage to increase in the future... more and more professional IT staff are starting to look for ways out.
      • by COMON$ (806135) * on Tuesday June 17, 2008 @02:31PM (#23827479) Journal
        Exactly, all of which cascades from a lack of project management. IT project managers are soooo rare no adays that everyone is scrambling to hire them. A good IT project manager will manage each of the problems you noted above. Sys Admins and Dev Gurus are not Project managers. But they get put in the position of being one constantly because upper management doesn't know the difference. It is a completely different skill set. You wouldn't make a simple accountant a CFO or your HR manager a CEO. Sure there is an aspect of accounting to beinging a CFO and there is an aspect of HR to CEO but those are well defined fields that people know how to sniff out good fits for them. However the Professional IT project manager is such a new concept that general managers think any IT guy can fit the bill.

        It all comes down to the fact that somehow the common business sense that people have in every other area seems to go out the window while they are thinking about IT.

        • Re: (Score:3, Interesting)

          by drsmithy (35869)

          Sys Admins and Dev Gurus are not Project managers. But they get put in the position of being one constantly because upper management doesn't know the difference.

          No, they get put into the position because they're inevitably the poor fuckers who have to try and pick up the pieces when the shit hits the fan - usually because they're the only ones who have the slightest inkling of how everything actually fits together.

          Most sysadmins I have met have a fairly limited grasp on the actual business aspects of run

        • Re: (Score:3, Insightful)

          by MadKeithV (102058)

          IT project managers are soooo rare no adays that everyone is scrambling to hire them. A good IT project manager will manage each of the problems you noted above.

          Everyone, repeat after me: Project Managers are NOT Managers . They are glorified Excel & chart monkeys that are expected to report to their boss how well it is going without having any authority at all to actually get reliable data, much less influence what happens. They spend endless hours arguing with a client that didn't want to spend 3 minutes actually explaining what they wanted about how the product doesn't deliver the functionality they never asked for. It's a thankless, shitty job, so I st

      • by Curlsman (1041022) on Tuesday June 17, 2008 @03:36PM (#23828611)
        I have a theory about the missing senior managers with useful skills: My father talked about his teaching debate in high school in the mid '60 to late '70 in central California (then moving on to a community college), where he said that many of the most socially active "lets change the world for the better" students he ever taught went to Vietnam and never really came back, in one way or another. Those people would now be in their 60s, ten years older than I, and their influence would be reaching their peak. Those people are the leaders and mentors that I feel have been missing from the last third of the 20th century.
    • by Anonymous Coward on Tuesday June 17, 2008 @02:27PM (#23827397)
      It is unfortunately common to knee-jerk a development problem by adding more management.

      A project manager who doesn't actually have the skills it takes to make a project successful will be as bad or worse than no project manager at all. Hiring/retaining more of them will just multiply the problem.

      It is very difficult to interview for and find good project managers. The talent pool is just teeming with people who are not skilled developers, and would to love to have a job that is, essentially, just telling other developers to do their jobs. There is tremendous incentive for people who are not competent to be a project manager (or much of anything else, for that matter) to fight tooth and nail for PM jobs. When you hire such a person, your project usually fails, or if it does succeed it is despite, and not because of, the best efforts of your project manager.

      Another problem: the best project manager in the world won't get you results if you disempower him or her. I have seen it happen often that the executives see a project slipping and shift into micromanagement mode. At that point, the project manager just becomes a mouthpiece, and the company has robbed itself of the value of their paid talent. If you can't trust your project manager to tell you when a goal cannot be achieved, or when more time must be allocated to some task that doesn't have obvious functional benefits, or that a deadline must be extended, then you have either hired a lemon or you are involving yourself too much in his job. In either case, your project will suffer because of it.

      Ok, I will stop ranting now. The bottom line is...more management doesn't solve problems. The right amount of *competent* and *properly empowered* management does.
    • Re: (Score:3, Insightful)

      by glgraca (105308)
      I think we have too many already. The real problem is either that they don't say what needs to be said because they don't want to make waves (they'll twiddle with their Project schedule and pretend that all will be alright) or that upper management simply won't take no for an answer (and will tell them to twiddle with their Project schedule to make it alright).
    • by dedazo (737510) on Tuesday June 17, 2008 @02:39PM (#23827667) Journal
      Not really. I've worked with shitty PMs but also with good ones (in large projects) where the fault lies entirely on the people above them.

      On a project a few years ago (your typical Fortune 500 $LARGE_COMPANY here), our PM was forced to declare that a large release that had taken 6 months to get to "it's kinda working" was "complete" and shipped to UAT even though system testing was incomplete and all we did was give the end users a pile of steaming shit. But the director of the group got to "meet" his deadline, and therefore get his much-desire performance rating.

      Of course fixing bugs once the app is in UAT is four times as difficult as in the integration environment, with the corresponding lag in defect correction time. So UAT went on and on and on... until it was supposed to be the final release date. Said users were hysterical and pissed off, and said director was out of his fucking mind trying to come up with inventive ways to ship said steaming pile of shit to production while blaming someone else for the smell of said pile.

      His first executive action was to fire the PM and have him escorted out of the building (he was a contractor like me). His second action was to request that the Offshore Solutions team add four more developers to the already swelled-beyond-comprehension development team in India. You know, throwing bodies at the problem. The next thing was to go to his VP and claim that he had been misled by the PM, who by this time was checking out the classifieds at home and therefore unavailable for comment.

      In the end, we all went through the usual death march and shipped the thing about three weeks late. The director got his rating (not his fault you understand) and the users had to deal with the remnants of the steaming pile of shit. I get paid either way so no skin off my ass.

      Projects are late (or they fail) because the people who are supposed to be in charge of delivering them have no fucking clue as to how software is developed. Fix that problem, and you'll ship all the software you want on time and under budget.

      I'm fortunate to be in a project right now where the guy in charge is a former developer who doesn't require a bonus to pay his mortgage, and all the two PMs do is move little bars on an MS Project file while mercifully leaving me and my team alone to actually write the software. We've released two major versions of the app so far the past two years and are on track to deliver the third version sometime this October. On time and under budget. The secret? Iterative development (SCRUM-like) with heavy user involvement in feature sprints. No waterfall bullshit for me anymore, thank $DEITY.

      /Rant over, back to work.

      • by COMON$ (806135) *
        Very insightful!

        That is what I was getting at. In my opinion you need PMs with some real world experience working in projects. After all you need to know what is going on below before you can paint the big picture. However, a PM should only report to the CEO, cut out all the bull. Get the project scope and draw out the details then let the PM take over. Don't fire, rehire or expand without the PM's explicit permission. At best the CEO should be asking members of the project team to review the PM to ma

  • Interesting line (Score:5, Insightful)

    by UnknowingFool (672806) on Tuesday June 17, 2008 @01:57PM (#23826769)

    Two consultants rewrote the 140,000 lines of [original obscure language] into 4200 lines of Java. The Java version runs as fast on a laptop PC as the original version runs on a high-powered UNIX server.

    Come on now, COBOL isn't that bad. :P. But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was.

    • by Chirs (87576) on Tuesday June 17, 2008 @02:08PM (#23827017)
      Depending on where the bottlenecks are, Java could do reasonably well. (And I say this as a professional kernel developer that works mostly in C, assembly, and shell scripting.)

      The bulk of most apps is not a hot path and therefore the language is not as important. Even in the hot paths, algorithms often count more than the language. Once a suitable algorithm is determined, performance-critical things are often best written in other languanges (and if it's really critical, in assembly).
    • Re:Interesting line (Score:5, Interesting)

      by jd (1658) <imipak&yahoo,com> on Tuesday June 17, 2008 @02:13PM (#23827137) Homepage Journal
      Java isn't the language for highly compact code, either. The original could have been any one of a hundred business languages, but most archaic business languages are fairly compact. That they could get such a high level of compression does show bad coding.

      ObOwnExperience: One time, I had to do some maintenance work on a very large piece of badly-written and cruft-ridden code, ended up rewriting large tracts of it, reduced its source size by an order of magnitude and the binary size by three orders of magnitude. Also found some buffer overflow Heisenbugs which the previous maintenance guys had known about but bypassed by padding the object files. There's something... bothersome about corrupting a file in order to make a bug not be visible.

    • by SuperKendall (25149) on Tuesday June 17, 2008 @02:19PM (#23827229)
      But seriously Java isn't the language you would use for high performance but rather high portability

      That old myth? That hasn't been true for many years now, for server side code anyway (which this was describing). Modern JIT compilers make java as fast, and sometimes faster (since you are optimizing code as it runs and not statically beforehand).

      But no language will help you if you lack discipline or the ability to code (both of which seemed lacking in this case).
    • by glgraca (105308)
      For portability, there's no way Java could beat Perl: http://www.cpan.org/ports/
    • Re:Interesting line (Score:4, Informative)

      by bfwebster (90513) on Tuesday June 17, 2008 @02:34PM (#23827551) Homepage

      Come on now, COBOL isn't that bad. :P. But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was.

      The point of that observation was exactly that: a rewritten version in Java, running on a laptop (and we're talking about a laptop several years ago), was faster than the original implementation on much-higher-powered hardware. It was also nearly 2 orders of magnitude smaller (in LOC). ..bruce..
    • by msormune (808119)
      Well, there's other things good about Java, such as massive support from other Java developers across Internet, literature and major vendors that come to mind...
    • That 4k in java isn't 4k in freshman comp sci java. It's going to be leveraging widely used libraries that have millions of SLOC and a wide deployment base. Reading between the lines, I would be surprised if the tiger team didn't use the same tools as countless midsized projects that are maintained by teams of a few dozen at most. You can do a phenomenal amount in little code if you use the right frameworks and some decent xml configuration files.

      In fact my coworkers and I have noticed an extremely frust
  • or at least a hint, so we can understand better the reality we live in. It could as well be SCO or some mediocre company - in that case, it would be meaningless. But what if it was Yahoo! or Microsoft?
  • by starX (306011) on Tuesday June 17, 2008 @01:58PM (#23826805) Homepage
    From TFA:


    The FUBAR project keeps being touted as a world-class development team, but it is not producing world-class, or even minimally-professional, results. This already shows up in the project delays and quality issues of the releases to date. What the team is producing will not only be very difficult to support and modify, it will in all likelihood be unusable, resulting in a complete failure of the FUBAR project.


    Sounds like Vista to me...
  • by g0bshiTe (596213) on Tuesday June 17, 2008 @01:58PM (#23826827)
    That "FUBAR" project is Duke Nuke Em Forever.
  • Two consultants rewrote the 140,000 lines of [original obscure language] into 4200 lines of Java. The Java version runs as fast on a laptop PC as the original version runs on a high-powered UNIX server

    Okay, ummmm, I'm gonna need some more detail on this statement.
    • Re: (Score:3, Insightful)

      by jellomizer (103300)
      Not to suprising. Older Languges didn't have such a rich default library set.
      Obj.sort() (using a fast sorting algorithm) vs. a quick to program bubble sort on the object can obtain performance gains with little extra code. You can write a Web Server in 50 lines in Python vs. 1000 lines in C and still missing functionality in C. That is just because Python has a web server object that intern executes the extra code needed it to run. The same from converting say from ADA to Java. You have a richer languge th
  • Sigh... (Score:5, Funny)

    by fahrbot-bot (874524) on Tuesday June 17, 2008 @02:03PM (#23826923)
    I first read this as "Anatomy of Runway Project" and thought of Heidi Klum [bravotv.com].
    I am *so* disappointed with the actual article...
  • by IANAAC (692242) on Tuesday June 17, 2008 @02:07PM (#23827005)
    You get someone with a heavy german accent who will tell you you are either in or you are out. We'll call her the director. Then we'll get a really tanned queeny man to critique verything you do. We'll call him the Project Manager. Oh and don't forget his sidekick who edits everything you do down. We'll call her QA. Every once in a while there will be a different person who comes in each week and gives his input, which really means nothing to you, since he hasn't seen any of your progress throughout. We'll call him the CEO.

    Then there's that person who's "kind of a big deal" and thinks the project is "fierce". That would be the senior administrator.

    Oh wait. This isn't Project Runway"?

  • by bfwebster (90513) on Tuesday June 17, 2008 @02:08PM (#23827021) Homepage
    I have a dedicated server and have had slashdotted postings before that haven't brought the server down. I've e-mail the support team to see what's going on. ..bruce..
  • I'm sure that there are other similar companies out there, but much of the language and all of the circumstances seem very familiar. Just curious, but how many other companies use the term "deliverables"? IBM, after purchasing Rational Software, decided that it was a good idea to move all projects to this process. About 2003, there was a huge stir within the company to document everything into a "process" and wasted months (nay, years?) in fluff process documentation that yielded no benefit. It is very
  • This report is little more than a walk through of the textbook examples that cause project failures, and what the possible consequences are. Interesting, but nothing new to those already in the industry. A lot of these symptoms are present in every project (not just the lost-cause ones). Most can attest to this.

    With some more detail this firm would make a great textbook example for future students. What was the end result of this project, or is it still active?
    • by bfwebster (90513)
      Remember that this was a memo written for upper management at BigFirm, not a published case study. What caught my attention, when I rediscovered the memo a few days ago, was how pervasive, broad and serious the problems were, all in one project.

      As the first paragraph of the post notes, the project was eventually killed. ..bruce..
  • Seen it before (Score:3, Informative)

    by UnknowingFool (672806) on Tuesday June 17, 2008 @02:13PM (#23827131)

    Note that the "ABC" consultants were a small part of the overall project team and had been brought in relatively late by "BigFirm" in an attempt to get the "FUBAR" project into production; they neither initiated nor managed the project.

    I've seen this so many times with the big consulting firms. They low ball the bids. Then they send in kids who were just handed their degrees and a manual about some technology and told to implement the technology at a client's site (basically it's the only people they can afford with the bid). It goes downhill because their lack of experience and lack of project management. Later the big consulting firm brings in a subcontractor to fix the issues (mainly because the client refuses to pay anymore and may have milestones/clauses that allow them not to pay). The subcontractor usually is smaller, has more expertise, but costs much more. But they are given a huge and seemingly impossible task. Sometimes they can rescue the project. Sometimes they can't.

    • by bfwebster (90513)
      I've certainly seen that pattern as well, but it's not what happened in this case. In this case, the development team was primarily in-house through most of the project. The consultants were brought in by BigFirm late and in small numbers. ..bruce..
  • by zazenation (1060442) on Tuesday June 17, 2008 @02:14PM (#23827153)
    approach to project development. "If we hire twice as many programmers, we'll finish it in half the time!"

    I ran into this career driven mid-level manager problem-solving approach regularly in the 90's before many of them vaporized (remember DEC?) Time has not changed human nature or incompetent managers.

    The PM's of these projects tended to be big on contrived dog-and-pony shows too as I recall.
  • by analog_line (465182) on Tuesday June 17, 2008 @02:23PM (#23827319)
    From large companies to small, it's the single biggest problem they all have. Decisions makers don't want to hear the truth, no matter how loudly they protest otherwise. Anyone with intellectual honesty that doesn't have a previously won huge level of trust from a decision-maker is almost invariably thought to be lying. They all want to have their cake and eat it too, and they will throw money at anyone that tells them they can. Even after getting burned by the consequences of their decisions, less than half (in my experience) bother to try and learn from the failure. Most of them blame the honest person (if they did nothing and as a result failure happened) or latch on to the next person willing and able to lie even more convincingly than the last guy.
    • by rsw (70577)

      I was about to post almost exactly the same thing.

      This Christmas I'm going to buy a stack of The Mythical Man-Month [wikipedia.org]s and leave them on all the managers' desks around here...

      -=rsw

  • by ubercam (1025540) on Tuesday June 17, 2008 @02:39PM (#23827665)
    Check out the story here [winnipegfreepress.com].

    A nice little 3.5 year IT boondoggle that cost a cool $70 million and cost one board member of 19 years his job. It all just came to light last month. It made some pretty big headlines around these parts as well.
  • by spaceyhackerlady (462530) on Tuesday June 17, 2008 @03:07PM (#23828139)

    We've all gotten burned on projects that got out of hand, but I often wonder why it happens, over and over. Hubris?

    I've seen projects where the requirements document was 1000 pages and growing exponentially. For an email server. I remember one project where it didn't matter if code even compiled: we had to ship what we had, because we couldn't delay any further. I made the mistake of expressing my views to the wrong people on that one, and was told in no uncertain terms to shut up if I wanted to continue working there.

    I've seen more than one project fall flat on its face because the original requirements were wrong, like trying to develop PC software for an industry that was 100% Mac.

    ...laura

  • Not Root Cause (Score:5, Insightful)

    by Aaron M. Renn (539) <arenn@urbanophile.com> on Tuesday June 17, 2008 @03:25PM (#23828435) Homepage
    I read this with interest as I have been involved in large scale IT development projects for various corporations for the better part of 15 years. This memo makes it appear as if the problems in the project were execution related: bad management, poor quality control, bad architecture, performance problems, etc.

    In my experience, it is actually not that common for an experienced team to fail largely on execution problems. Rather, as I like to say (call it Renn's Law if you'd like): "Most failed corporate software projects failed before the kickoff meeting". Usually the signs of failure were there all along, before the project even officially got started.

    Here are some of the key things I've seen lead to problems, most of which are not directly related to the core development (design, build, and test) of the project:

    - Lack of an identified executive sponsor
    - Failure to identify a limited subset of people who are empowered and responsible for articulating the business requirements of the system
    - Lack of clarity as to the actual goals to be achieved or the underlying problem to be solved.
    - No shared vision of what a successful outcome would look like among the various stakeholders
    - Project positioned as an IT-centric solution to a business-centric problem without a corresponding business strategy, process, and change management plan in place.
    - Insufficient resources (time, money, people) allocated to the project
    - Lack of qualified staff in key roles (data architect, functional lead, etc)
    - Poor governance and scope control
    • Re: (Score:3, Insightful)

      by bfwebster (90513)
      Aaron:

      Great post. You'll find a less-general version of Renn's Law in The Art of Systems Architecting by Maier and Rechtin, in Appendix A ("Heuristics for systems-level architecting"): "In architecting a new software program all the serious mistakes are made on the first day." (p. 271). I have quoted that many, many times.

      I like your list of key problems. I'm currently writing/editing a book (Pitfalls of Modern Software Engineering) and looking for additional contributors. If you're interested, drop me an e
  • Its Obvious (Score:3, Informative)

    by micromuncher (171881) on Tuesday June 17, 2008 @04:34PM (#23829525) Homepage
    The article points out that project management didn't do grass roots valuation or [pause] management. I would bet that the PM for this project has a PMP cert. As a former tech lead/architect for a death march type project, I can honestly say sometimes people in roles such as mine do have the expertise to advise management of risk, complexity, and time/cost. The biggest obstacle is the mind-set and experience of the PM and their bosses. For example, the last project, I mentioned certain things were high risk and/or would take significant time due to complexity and "unknown dangers." The question put to me was "Can we solve this by throwing more people at the problem without changing the time-line [that was picked out of the air]?" My response was, "Its the mythical man month." The blank stare I had in response forced me to explain the concept of overhead logistics, ramp up time, and cost/time trade-off features and risk. [The unfortunate side effect of me educating the PM about her job made me a threat and obstacle to be removed.]

    You can have a kick azz senior team and still fail.
  • by PPH (736903) on Tuesday June 17, 2008 @04:35PM (#23829557)

    I've seen screw-ups totaling hundreds of millions (that we knew about). Possibly billions if some forensic accountants could be sent in. I've worked on the fixes for a few of these. Some so simple that it took half a dozen people about 6 months to successfully build a replacement.

    So, where does the money go? I mean $250 million USD on a f*ck-up? The perpetrators aren't driving Ferraris and Bentleys, so I doubt it was embezzled. In truth, project FUBAR was never actually shut down. It still exists as a server with some documents. This allows the company to depreciate the development costs and not have to take a write-down that Wall Street would notice. There's another reason the project, while brain-dead, has its corpse propped up at board of directors meetings:

    This outfit is, among other things, a government contractor. They just lost a big one to a competitor, which they are appealing. Part of the reason for the loss is that gov't inspectors, having become aware of the true scope of woe, selected the better alternative. One (rare) example of the gov't actually looking out for our pocketbooks. But in the end, I suspect they (we, the taxpayers, that is) are destined to lose the appeal, since the project is not officially dead and can't be used as the basis of a negative performance report upon which the bid decision was based.

  • by viking80 (697716) on Tuesday June 17, 2008 @06:49PM (#23831705) Journal
    TFA describes a project in complete disarray and a failure on all level. Despite this level of failure, TFA is pretty much anecdotal. TFA has no hard metrics or any other solid data to support the anecdotal conclusions. It is very possible it is accurate, but if a project is a complete mess, it should be easy to get good solid metrics that document this.

    The fact that the author of TFA has none of this makes his assessment not only worthless, but places his work in the same category as the mess he was assessing.

    If you need to slaughter a project, you need to:
    a. Have a measurable set of goals for the project
    b. Measure the current status against the goals
    c. conclude status.

    It would suffice to give a list of the different functions with number of showstopping defects for each function together with a description of the most glaring defect in each of the functions. Just pulled out of the bug tracking system verbatim would do. Example of glaring defect: "When the user push the OK button on screen XYZ, the server crashes, and all the data is lost. There is no workaround"
    • Re: (Score:3, Informative)

      by bfwebster (90513)
      Assuming that "TFA" refers to the memo I posted, I think you're confusing the audience and scope of it the memo. This was for a senior, technically-oriented executive who was concerned over the gap between the optimism that was being reported upwards to him/her and the constant schedule and budget overruns that had been a reality for (by this point) a few years.

      The memo was never indented to be a close-detail, point-by-point listing of existing flaws in the project; for starters, that probably would have fi

"For the man who has everything... Penicillin." -- F. Borquin

Working...