Forgot your password?
typodupeerror
Software IT

Identifying (and Fixing) Failing IT Projects 144

Posted by ScuttleMonkey
from the if-it-aint-baroque-don't-fix-it dept.
Esther Schindler writes "Often, the difference between the success and failure of any IT project is spotting critical early warning signs that the project is in trouble. CIO.com offers a few ways to identify the symptoms, as well as suggestions about what you can do to fix a project gone wrong. ' The original study (which is still sometimes quoted as if it were current) was shocking. In 1994, the researchers found that 31 percent of the IT projects were flat failures. That is, they were abandoned before completion and produced nothing useful. Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features. "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success rate is up to 35 percent." The remaining 46 percent are what the Standish Group calls "challenged": projects that didn't meet the criteria for total success but delivered a useful product.'"
This discussion has been archived. No new comments can be posted.

Identifying (and Fixing) Failing IT Projects

Comments Filter:
  • by Reverend528 (585549) on Wednesday July 18, 2007 @05:01PM (#19906737) Homepage

    Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features.

    I have to feel that this number would be much higher if project managers would just learn to allocate an infinite budget and an unlimited timeframe.

    • My feeling is most of these "successful" projects were small-team, hands-off affairs. It's easy to do good work when you have a fixed goal (or set of goals), a responsible team and nominal oversight. The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).
      • The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).

        Try planning a project that will take 5 years and $10 million.

        People WILL leave the organization during that time. They will be replaced. If it was a tech, will the new tech do things the same way as the old one? Will you have hammered down your p

        • by j-pimp (177072) <zippy1981 @ g m a il.com> on Wednesday July 18, 2007 @08:16PM (#19908793) Homepage Journal

          The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).

          Try planning a project that will take 5 years and $10 million.

          People WILL leave the organization during that time. They will be replaced. If it was a tech, will the new tech do things the same way as the old one? Will you have hammered down your process so that s/he will HAVE to do it the same way?

          Will any tech worth his salt WANT to do things the same way as the old guy without questinging anything? Personally when I enter a new company, a large part of "getting adjusted" is fighting every foreign idea tooth and nail. I come to terms with them shortly, but I can't accept them as useful until I see them.

        • by GooberToo (74388)
          It can be done...but it's hard.

          There are two items I see which always cause problems. One, failure to properly identify and document the requirements. Two, failure to resist scope creep or requirements change. In almost every case, these are a failure of management on up. Usually at the behest of marketing. Worse, I find the more input marketing has in large projects, the more screwed the project will become.

          For whatever reason, the vast majority of companies refuse to treat project requirements as a p
    • by Chris Burke (6130)
      Based on those numbers and my own experience, my question is: Instead of trying to "fix" all these broken IT projects, why not just shit-can them before you've spent X many man-years on them? So many of them fail, but the failure of the project does not cause the failure of the company. In other words, they were non-essential to begin with and whatever benefit they might have added is offset by their cost. Dump em.

      Kinda like when my company decided to replace their functional but distinct HR, travel, an
      • by Vancorps (746090)
        You wouldn't by any chance have tried to deploy Navision have you? hahaha... your post actually made me laugh. I had to inherent a Navision deployment, imagine my surprise when I wanted to replicate the data to another server so I could have an online backup. Whoops, the GUID column getting added stops the Navision client from being able to do anything!
      • by julesh (229690)
        Based on those numbers and my own experience, my question is: Instead of trying to "fix" all these broken IT projects, why not just shit-can them before you've spent X many man-years on them? So many of them fail, but the failure of the project does not cause the failure of the company.

        Agreed. In fact, agile development methods consider it a success when this happens: one of the stated aims is to deliver the best value for the business, and if that is best delivered by not producing software, it's the deve
    • Anything is possible given enough time, enough money, and someone else to do it for you.
  • problem (Score:4, Funny)

    by SolusSD (680489) on Wednesday July 18, 2007 @05:01PM (#19906741) Homepage
    at least a large part of the problem are the incompetent masses that we refer to as "IT specialists". I'm surrounded by them.
    • by Duhavid (677874)
      So the spontaniously appear, or did someone ( incompetently ) hire them?
      Idiots will seek jobs, perhaps idiots will hire them?

      Or to make a direct statement, management needs to own the issue of
      who they hired.
      • by BVis (267028)

        So the spontaniously appear, or did someone ( incompetently ) hire them?

        Several possibilities:

        1) HR is blatantly incompetent at recruiting IT workers;
        2) The recruiters that HR outsourced to are blatantly incompetent at recruiting IT workers;
        3) The idiot is someone's brother-in-law (or other forms of nepotism);
        4) Management refuses to offer a salary/benefit package that would allow for the appropriately talented worker to be hired;
        5) The idiot involved is good at selling themselves in an interview;
        6) Time ra

        • by Duhavid (677874)
          "Management is allergic to accountability."

          Quite. They are still responsible ( in the causation sense )

          "I kid you not, the beta of the next version of our product is being managed by the marketing director"

          Oh, I believe you. I worked at a place where the VP Eng walked off
          one day, and they appointed the marketing director to head the department.
          I think that company was already headed for the dustbin by that point,
          and decision-making like that is probably why.

          "I really didn't want to be in a position to dus
      • by SolusSD (680489)
        this is true... the real problem lies in the fact that in a lot of software companies (like the one i work for), management has no reference for what incompetent is-- i mean, they're tasked with hiring people that are suppose to know more about the IT field than themselves. To put it in a not-so-polite way, idiots are tasked with trying to _not_ hire idiots... and, of course, it doesn't work.
  • First sign (Score:3, Funny)

    by Anonymous Coward on Wednesday July 18, 2007 @05:01PM (#19906745)
    Your consultants are all Elbonian
  • AA meeting? (Score:2, Insightful)

    by disasm (973689)
    This reads like an Alcoholics Anonymous meeting:

    Step 1: Get everyone to admit the project has a problem
    Step 2: Figure out what that problem everyone admits is wrong really is
    etc...

    Sam
    • Re:AA meeting? (Score:5, Insightful)

      by Tackhead (54550) on Wednesday July 18, 2007 @05:18PM (#19906929)
      > Step 1: Get everyone to admit the project has a problem
      > Step 2: Figure out what that problem everyone admits is wrong really is

      1. We admitted we were powerless over this schedule -- that our project had become unmanageable.
      2. Came to believe that a Power easier to blame than ourselves could restore us to schedule.
      3. Made a decision to turn our will and our lives over to the care of the Consultant as we hired Him.
      4. Performed an overreaching and mindless team-building exercise.
      5. Admitted to the Consultant, to ourselves, and to the CEO the exact nature of our incompetence.
      6. Were entirely ready to have the Consultant take over our jobs duties.
      7. Humbly paid the Consultant to fix it for us.
      8. Made a list of all persons we had harmed, and became willing to make suck up to them all.
      9. Sucked directly up to the CIO wherever possible, except when to do so would involve our beating him at golf.
      10. Continued to perform team-building exercises, and when we thought it was silly, we still faked it to HR.
      11. Sought through kickback and corruption to improve our friendship with the Consultant as we understood Him, paying only for Coverage of Our Asses and the budget to carry that out.
      12. Having had a Machiavellian awakening as the result of the project's inevitable failure, we fired the Consultant and resolved to carry the blame to other departments, and to re-hire the Consultant next year so that we can practice these principles when the next project goes off the fucking rails too.

      • Bravo!
      • by Kjella (173770)
        Sounds remarkably familiar, expcept I'd replace "re-hire the Consultant" with "hire a new Consultant". We hire out professional ptoject managers, and it's common enough that it gets covered. As in, things that indicate you're the fall guy, what do to if you're the fall guy etc. To me it's surprising how many projects are recogniaed early as being crap, yet still go on. Once you've committed to a project, it's always hell admitting you made a mistake even when it's painfully obvious.
  • by The_REAL_DZA (731082) on Wednesday July 18, 2007 @05:05PM (#19906781)
    That 31%-flat-failure rate sounds just about right; about a third of the projects I've worked on over the last 15 years have been complete flops (with the usual list of various reasons from "bad idea to begin with so it needed killin' " to "we changed bosses and since your project wasn't the new boss' idea..."), but I'd have to challenge the notion from TFA that they "produced nothing useful", because I've learned something I didn't know and wouldn't have otherwise known from each of them -- in other words, I'd count them all as at least partial successes because I personally gained something from them.
    • Re: (Score:3, Informative)

      by Dan Ost (415913)
      I agree completely. The successful projects I've been on recently were all successful because of things that I and other team members learned on previous projects (successful or otherwise).
  • by asphaltjesus (978804) on Wednesday July 18, 2007 @05:06PM (#19906809)
    Seriously.

    Most IT projects I've been involved with that got to some difficult points suddenly had no one willing to discuss them, much less do anything.

    Woe is the girl/guy with no authority brought in to get the project back on track.
    • Re: (Score:2, Insightful)

      by cromar (1103585)
      Woe is the girl/guy with no authority brought in to get the project back on track.

      Hey, at least I get good salary and benefits! Coding a huge web application by myself for 7 months wasn't so bad: I like coding and money. Now I just hope they find something else for me to do... I hate being underworked.
  • consultants (Score:5, Insightful)

    by Lord Ender (156273) on Wednesday July 18, 2007 @05:07PM (#19906813) Homepage
    When management wants a project that IT knows is bound to fail, our company will sometimes hire an outside consultant to run the project. That way, half way through the project, as we miss milestones, we can fire the consultant and blame it all on him. He gets paid, and we get out of the blame. Win-win.
    • That's all part of the consulting game, but you have to play fair. Offer a fixed-price contract with no early termination penalty, or provide an escape clause that pays some fair amount if the contract is terminated early. I've known a couple of projects that badly burned some consultants, because management knew the project was going to fail, but they still put the contract out light on the rate but heavy with incentives. And what really sucks is, you'd like to say "Boy, you'll never catch me working fo
      • by RajivSLK (398494)
        but when they're one of the major players in town,

        Or moving to a different town?
        • Re: (Score:3, Interesting)

          by Dan Ost (415913)
          Marry a doctor. I really do like what I do, but I also like the fact that what I do is OPTIONAL.
    • by canuck57 (662392)

      When management wants a project that IT knows is bound to fail, our company will sometimes hire an outside consultant to run the project. That way, half way through the project, as we miss milestones, we can fire the consultant and blame it all on him. He gets paid, and we get out of the blame. Win-win.

      That deserves a repeat. You work for a good CIO with a vision and spine. As this article didn't tap into why many I/T projects really fail. Here are some of what I have seen:

      • Lack of management commitment
  • by ucblockhead (63650) on Wednesday July 18, 2007 @05:09PM (#19906843) Homepage Journal
    Half of all outgoing port 80 requests are to slashdot.org.
  • by mcrbids (148650) on Wednesday July 18, 2007 @05:11PM (#19906861) Journal
    The article starts out by stating that "agile project management is notoriously least effective on very large projects." but then goes on to propose using Agile Programming techniques to fix it! Such as:

    From TFA:

    "Small, discrete and often" are the guidelines for the milestones for a successful project.
    And from the Agile Manifesto: [agilemanifesto.org]

    Deliver working software frequently, from a
    couple of weeks to a couple of months, with a
    preference to the shorter timescale.
    From TFA:

    "Make sure everybody really agreed to what the project is going to do," he says. "Make sure everyone has the same goals even when they have conflicting agendas."
    And from the Agile Manifesto:

    Build projects around motivated individuals.
    Give them the environment and support they need,
    and trust them to get the job done.
    This is just another shoddy example of "journalism" from an IT rag whose job it is to produce buzzword-laden tripe that can be used to get advertisements in front of tech weenies. Ultimately, the actual value of the articles in mags like CIO.com are marginal at best, and usually only slightly more interesting than the advertisements!
    • Ultimately, the actual value of the articles in mags like CIO.com are marginal at best

      Not so! Without these articles, how would CIOs sound clued-in when they gathered around the luau table during that big "experience sharing" conference at an island resort? How else would they know when to nod sagely while someone else relates their tale of SAP implementation? Or when to raise their eyebrows in appreciation of one of their peers' business savvy when they hear about how one of them deftly juggled a crisis during cutover from their legacy system to the new web-based one when they discovere

    • This is just another shoddy example of "journalism" from an IT rag whose job it is to produce buzzword-laden tripe that can be used to get advertisements in front of tech weenies.

      Bing! Go to the head of the class - this is really rather well stated. The phrase 'buzzword-laden tripe' is a particular jewel, and I hope you won't mind if I use the ever-lasting shit out of it.

    • by julesh (229690)
      Are you trying to say that building software in short increments and with a supportive atmosphere for the programmers isn't a good idea? Because from where I'm sitting, both of those look like really good plans, whether you're doing agile development or not.

      You make it sound like the advice of the article is to do agile development, but that's really not what it's saying at all. Yes, a couple of their suggestions happen to overlap with agile methods, and one of the people they're quoting is an agile propo
    • The article starts out by stating that "agile project management is notoriously least effective on very large projects." but then goes on to propose using Agile Programming techniques to fix it!

      Project Management is not the same thing as Programming Techniques. Milestones are not the same as software deliverables. Also

      Build projects around motivated individuals.
      Give them the environment and support they need,
      and trust them to get the job done.

      These are good ideas even if you are not doing Agile Dev

  • by Anonymous Coward on Wednesday July 18, 2007 @05:13PM (#19906875)
    'Twas the night before implementation and all through the house,
        Not a program was working not even a browse.
    The programmers hung by their tubes in despair,
        with hopes that a miracle would soon be there.
    The users were nestled all sung in their beds,
        while visions of inquiries danced in their heads.
    When out in the machine room there arose such a clatter,
        I sprang from my desk to see what was the matter.
    And what to my wondering eyes should appear,
        but a super programmer (with a six-pack of beer).
    His resume glowed with experience so rare,
        he turned out great code with a bit-pusher's flair.
    More rapid than eagles, his programs they came,
        and he cursed and muttered and called them by name:
    On update! on add! on inquiry! on delete!
        on batch jobs! on closing! on functions complete!
    His eyes were glazed-over, fingers nimble and lean,
        from weekends and nights in front of a screen.
    A wink of his eye, and a twitch of his head,
        soon gave me to know I had nothing to dread.
    He spoke not a word, but went straight to his work,
        turning specs into code; then turned with a jerk;
    And laying his finger upon the "ENTER" key,
        the systems came up and worked perfectly.
    The updates updated; the deletes, they deleted;
        the inquiries inquired, and closings completed.
    He tested each whistle, and tested each bell,
        with nary an abend, and all had gone well.
    The system was finished, the tests were concluded.
        The users' last changes were even included.
    And the user exclaimed with a snarl and a taunt,
        "It's just what I asked for, but not what I want!"
    • I've somehow managed to never see that before, but I'll be printing and posting a copy of that fine work right above my desk (with the aforementioned last line highlighted and bolded!)
  • by The Media Mechanic (1084283) on Wednesday July 18, 2007 @05:14PM (#19906889)
    I haven't read the article but I would bet good money that they are allowing clueless managers and CEOs who gave very bad requirements in the first place, to determine if something was a success or failure. In other words, software is only as good as the initial requirements and design. If your client / customer is clueless then they will give you some hand-waving description of what they want ... something like "Listen, we need a new computer system that kind of does what the old one does, but just works better and makes more profits for us! Now hurry up and make it work, Code Monkey! Now excuse me while I retire to my executive suite / relaxation salon and get my manicure."
    ( Not that I'm bitter or anything. )
    http://blogs.warwick.ac.uk/images/steverumsby/2006 /01/30/dilbert20060121046729.jpg [warwick.ac.uk]
  • Heuristic methods (Score:4, Insightful)

    by mutterc (828335) on Wednesday July 18, 2007 @05:30PM (#19907075)

    Spotting a failing IT project: If it's a project, and it involves IT, then it's failing. (The summary's cited statistics bear this out).

    Fixing a failing IT project: Rewrite the laws of economics. (My experience bears this out). This may involve fiat, chemical means, or founding a new religion.

  • The definition of success has changed over the past 15 years. In the past, requirements would change without a change in deadline. Now with real project management, such as PMI/PMP, becoming more popular, requirements changes are costed. It's obviously easier to meet the latter definition of success.

    There have been some bona fide improvements in software development over the past 15 years: longer variable names, language-supported encapsulation, and inline documentation tags that allow for larger teams a

  • Failing Projects come form endless TPS reports and useless meetings As some time you spend more time of them then your real work and they are the only places the that the bosses get any info about the Projects as they are so dumb they waist IT time on showing them how do email 1-2 times a week and other easy things then the IT people don't have the time to fix things with the people who do the real work on the Projects.
  • Grain o' Salt (Score:5, Insightful)

    by vinn (4370) on Wednesday July 18, 2007 @05:40PM (#19907193) Homepage Journal
    I gotta say, I always take this kind of stuff with a grain of salt. As an IT manager (director, or whatever the hell you want to call it) I've got a little perspective on it.

    There's quite a few projects that we arguably start (probably even close to the figures quoted) that we don't finish. They're not failures, often I (me, not the department or project managers) had no intention of completing them anyway. Here's why some don't get done:

    1. I can't get it past the budget process. There's a time and place to pick your battles. Maybe throwing HR's new whiz-bang software project under the bus to make the operations manager's project swim along is worth it. It doesn't mean HR's project is a failure.

    2. We start a project to investigate a new technology. Hey - sometimes (dare I say most of the time?) the new stuff doesn't work as advertised. Sure, we've got an older 802.11b network running side-by-side our 802.11g. We looked at ripping it out and starting to get into the 802.11n, but it's not worth it right now. But the exposure to 802.11n was worth it. We'll revisit it next year (when Cisco gets an n product.)

    3. The "nice to do" list also creates some "failures". Boy, right now we need a strong asset tracking system. Well, screw it. We can track the licenses on paper as we've been doing. We've got more important things to worry about.

    However, the shit that needs to get done, gets done. That new accounting system? Hell yeah we're going to get that right.
    • by JonathanR (852748)
      I think you're confusing project prioritizing with delivering projects.

      Your first example about balancing the HR project with the operations manager's project seems more about resourcing and scheduling multiple projects than one or the other individually being a failure. The inability to meet HR's schedule expectation is a project management failure, since embarking on that project without knowing it can be finished on time and budget is a failure.

      I work for a large multinational engineering contractor, an
  • SAT Effect (Score:3, Insightful)

    by Reason58 (775044) on Wednesday July 18, 2007 @05:42PM (#19907209)
    In 1994, the researchers found that 31 percent of the IT projects were flat failures. [...] As of 2006, the absolute failure rate is down to 19 percent.

    I have serious doubts that IT projects have made any significant improvements in management efficiency in the last decade or so. More likely the people estimating timelines, budgets and features have learned from their mistakes and simply set the bar much lower than they did in the early 90s.

    It's the "SAT Effect" (tm). Why actually improve performance when you can simply tweak the metrics by which you measure?
    • have serious doubts that IT projects have made any significant improvements in management efficiency in the last decade or so. More likely the people estimating timelines, budgets and features have learned from their mistakes and simply set the bar much lower than they did in the early 90s. It's the "SAT Effect" (tm). Why actually improve performance when you can simply tweak the metrics by which you measure?

      Pardon, but as someone who's managed projects, it's a bit more than "tweaking metrics" or "moving

    • Re:SAT Effect (Score:4, Insightful)

      by nine-times (778537) <nine.times@gmail.com> on Wednesday July 18, 2007 @06:45PM (#19907925) Homepage

      You make it sound like a such a bad thing. I don't necessarily think it's just about "lowering the bar", but instead an issue of having realistic expectations. In 1994, having a dedicated IT department was still relatively new for many companies. To put it in perspective, people were still using Windows 3.1. The Internet wasn't even a blip on the pop-culture radar, and (IIRC) Netscape was just being released around that time. Most people understood practically nothing about computers and networks. In a lot of colleges, CS was still a relatively new major, and many colleges didn't even offer IT-specific majors yet. For a long time, the "computer experts" came out of other majors relating to math, engineering, and science.

      So it wouldn't surprise me at all to learn that the managers of IT projects in many companies had practically no idea of what they were doing. I wouldn't be surprised to hear that they had silly expectations about how things would work or what their new systems would allow. After 13 extra years of seeing the reality of computing and being frustrated by computers, one would think their expectations would be lowered somewhat.

  • One almost has to wonder if the current 35% "success rate" is for truly successful projects, as opposed to ones where the only criteria for success was completing it. An article [worsethanfailure.com] from WorseThanFailure (previously TheDailyWTF), originally intended to explain why the site's name had changed, does a nice job of explaining just why "success rates" can be misleading.
    • by Xiaran (836924)
      From personal experience I also found this dubious. I have work on projects that have been "declared" successful... sometimes despite the fact that I was still working on getting it fixed :) I was once working on a project that had to interconnect with a CRM project which was going badly. I was much surprised one friday to find a front page mention of the company email newsletter of how the CRM component had gone live. It was surprising because we 1. hadnt complete our testing and 2. they had no production
  • by Proudrooster (580120) on Wednesday July 18, 2007 @05:49PM (#19907275) Homepage
    If you aren't part of the solution, there is much money to be made in prolonging the problem. (My second favorite de-motivator)

    Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep. Unfortunately, while IT is bemoaned as incompetent, the truth is that most of the users are even more incompetent, yet the IT departments ask the users for INFORMATION.

    IMHO, You have to assign someone from IT to LEARN THE BUSINESS before trying to create solutions. For example, if you are creating an application for a Shipping Department, send people from IT to go work in shipping for a week and UNDERSTAND how the department operates and how it can be improved. Asking the users what they need without true understanding leads to disaster and inefficiency. If you gain understanding and insight into how to create a solution, you can make real improvements and possibly even eliminate inefficient/useless tasks and save labor.

    Scope Creep.... The old, hey while you are at it, could you just add one more feature to the program? You have to respond NO, but we will add that to the feature list for version 2.0 of the application. Imagine if Henry Ford tried to add all the features we have on the modern automobile to the Model-T. The Model-T wouldn't have ever been delivered. Creating software is an iterative process and just like car models you have to stop adding features at some point.

    Good Luck! Just remember, the problem is rarely technical.
    • by grcumb (781340)

      Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep.

      Based on that sentence, may I suggest that you also consider: 3) Poor QA?

      • I believe this submitter is talking about catastrophic project failure, as in "the project failed miserably". QA in my experience is not usually the cause of projects failing, unless you consider the classic Lorane 5 Rocket disaster. [umn.edu] or the iPhone Launch and AT&T melting down on activations.

        I am assuming this project has good DBAs and good programmers. Most shops have these, but these poor folks find themselves drowning in nebulous requirements and SCOPE CREEP.

        Personally, I operate on the "It co
    • Mmmmmm.

      A person with a functioning brain. The real world must frustrate you to no end.
    • by Black-Man (198831)
      In my experience... following up after disasters... developers can be part of the blame. I don't know how many times where I've seen a person who thinks they are all that and a bag of chips just doing something because its "cool" or its the latest tech "fad". Yeah... it pads their resume and most managers are clueless on the details anyways, so they get away with it. They'll even come in after the fact, fix their crap and become "hero's". Definite win-win situation.

    • by jafac (1449)
      You need to send your IT guys to S&R for a MONTH, not a week. Otherwise, you will miss that last day of the month, when 90% of the activity occurs.
    • by julesh (229690)
      Seriously, though the classic problem with IT projects are two-fold: 1) Unclear Requ2irements and, 2) Scope Creep.

      The two are one and the same, of course, because they both mean that the program you're writing might not be the one that's actually needed.

      IMHO, You have to assign someone from IT to LEARN THE BUSINESS before trying to create solutions.

      This is an interesting approach, and it certainly has merit. Another option, one espoused by the agile development community, is to have someone who already kno
      • I have studied the CMM [wikipedia.org] and it's implementation, and have determined through experience that having USERS feed REQUIREMENTS to IT results in "It's just what we asked for, but not what we wanted" results. I believe that IT must maintain an intellectual arrogance and lead with technology to drive more efficiency and better processes. IT has to be the one to stand up and ask, "Why are we doing it this way? Wouldn't it be better to consider this approach? Couldn't we combine these two processes or functions
    • by sane? (179855)

      If I had a dollar for every time a softie had blamed unclear requirements or scope creep for a project's failure - I still probably wouldn't have much with the way the dollar is plunging

      Point is, the world moves on, needs move on, things develop. If you and your methodology can't cope then I'm afraid IT'S YOUR PROBLEM. You need a different development methodology, a different approach that's more flexible. Its no good saying "this is the twentieth time a project has suffered from requirements creep" - its

      • Its YOUR responsibility to expect and be able to deal with real requirements change - stop whining.

        And this is why projects fail. Imagine building a house for a customer that comes out to the job site and asks the builders to make DAILY or HOURLY changes. Suppose he wanted to resize the basement after it had been poured. This would change the entire structure of the house, not to mention make the foundation weaker. The point is that it is RISKY, INEFFICIENT, and COSTLY to change a design in progress.
    • by gatesvp (957062)

      Hey man, I love your "spend time on the floor" concept. I'm behind that 100%, truth is, if I could convince everyone of the importance of this, I would book in a site visit to every client we worked for. I don't think that I have that sway yet.

      Of course, with Scope Creep, the biggest issue I've seen is usually the manager. Even with full-out change requests forms, I've seen managers lose stuff, or make non-transparent decisions about features. The best driver for controlling creep is having a next step. P

  • by John Hasler (414242) on Wednesday July 18, 2007 @06:13PM (#19907553) Homepage
    > "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success
    > rate is up to 35 percent."

    They redid the study excluding government projects?
  • Fix it: pick a new xml parser, and start again from scratch.
  • The formula is simple: (clear plans to produce features) / (features promised to customer or end user).

    In successful projects, that comes out to something like 80% or higher, while in unsuccessful projects you see at best 30%. The way this ratio is kept high is that in the initial planning stages you keep a technology guy in the room who can say no to the sales and end users (or sometimes "yes, but it will take you another 4 months and $300,000")
  • Projects with unclear goals, and unclear measurements for success, tend toward failure. Unfortunately, committees tend to design exclusively these, because being vague is how you keep your job. In case a project fails, describe it vaguely, so you can blame someone else and move on. This motif is repeated through human society, even politics. Who's to say the Iraq war wasn't one of those 31% of scope-creep, vague-goal projects?
  • by Aceticon (140883) on Wednesday July 18, 2007 @07:13PM (#19908193)
    As a contractor (aka freelancer) software engineer and analyst i have over the years learned to spot a number of indicators which are usually associated with the kind of groups/companies where software projects tend to be late and/or not deliver what the business needs. Here's a couple of indicators for that kind of place:
    - The bigger/more-complex projects have little or no analysis.
    - There is neither a formal Requirements Gathering stage nor (in Agile Programming) an easilly available user/user-representative with which to discuss business features.
    - Delivery of a project to a client is an unstructured process. In other words, there is no list of standard types of documents and deliverables to deliver which is common across projects.
    - Project planning does not have a built-in margin for unforseen problems and sometimes relies from the start in people working extra (unpaid) hours to make the budget.
    - Sales dictates the deadlines without consulting (or consulting but then ignoring) the technical side.
    - There are no specialized Testers.
    - There are no standardized software components, software frameworks, good practices or documentation for use across the company.
    - There is a vast number of software languages, software libraries or frameworks of different versions used across the projects done in the company. Similar projects use different languages/libraries/frameworks and/or use different major versions of those. Developers are totally free to choose the languages and libraries they want to use for the projects. Maintenability is not taken into consideration in the choice of languages/libraries which instead are chosen on the basis of "cool sounding", "fun" and "CV enhancing".
    - The project manager has little formal or informal power within the company beyond his subordinates (this is harder to spot but a surprisingly good predictor of failure).

    There's quite a lot more, but these are some of the more obvious ones and i've seen all of them already more than once.

    More in general, what software development environments where late or failed projects are common share is a failure to organize and/or a failure to prepare and/or lack of "soft skill" from project management and/or ignorance of the characteristics of the software development process.
    • Really enjoyed reading that one.

      Ive worked a number of projects (mostly defence related) that cover all the points above in spades, and they were all a joy to be part of.

      And Ive worked on large projects in large organisations that do none of the above .. at all. Yes, they were all disasters.

      Smaller organisations sometimes get away with it, because they have to - they dont have the meat in the budget or resources to do things 'properly'. Most of these 'survive' somehow, but not forever.

      I have found one at th
    • by Shados (741919)
      All of those aside like 2 are describing my current work environment. The last one on your list (the project manager not having enough power) is an incredibly huge one, that way, way too many people miss. My current project manager is a former software architect. He's SEEING all the problems, and he KNOWS how to fix them, but doesn't have the power to enforce it (neither do I unfortunately). So he's just watching the train wreck, trying to do what he can...its sad really.

      The requirements process is also a k
  • Annoying (Score:5, Insightful)

    by steveoc (2661) on Wednesday July 18, 2007 @07:31PM (#19908373)
    I find this article very annoying.

    So a bunch of companies (who all sell expensive proprietary project management software) get their heads together and conduct a study on project success/failure ratios .. and conclude that things are improving, and then attribute the improvements to things like .. This awesome new, expensive, proprietary project management software.

    Umm .. excuse me, but I have NEVER seen a project that was conceived AND executed solely by any number of 'project managers', using any form of project management tools, meetings, and other justifications for their existence.

    Projects are successfully delivered by good coders with good tools, and a thorough understanding of the requirements. There have been RADICAL advances since 1994 in the way that software is built, and its these advances more than anything else that lead to successful projects.

    Coincidentally, Prior to 1994, if you were working in software, you were working blindfolded with one hand tied behind your back. By 1995, this Linux thing starts gaining momentum, and very quickly we see this massive rise of open source projects in a huge number of areas. Prior to 1994, an SQL engine is some mythical binary blob that you have to purchase from Oracle or others .. after 1994, an SQL engine is something tangible that you can download of the internet and get your hands dirty with the source code. Ditto with 'internet enabling' your applications - Ditto with having a real freely available and portable C compiler - ditto with having a raft of languages (perl, PHP, etc, etc) that open up new possibilities.

    Suddenly, as a software coder, the blindfold is removed and you have both hands free to work. Whatever problem domain you are likely to encounter, you can easily find open source projects that have already dug very deep into that problem domain, and have code and design discussions open for general peer review.

    So its no surprise that in this new and extremely fertile post-1994 world .. software projects are more successful. But can you simply attribute that to a small selection of expensive, proprietary project management tools ? WTF, I dont think so.

    Another thing to note is that the core developers in a lot of projects are older and wiser now. Many are well past the wrong side of 40 and still coding day and night for the sheer joy of the art. Perhaps they have also grown more politically savvy, and know how to take management speech, distill the essential elements out the mouths of managers, and then go away and do the project their own way regardless. Except this time, they know how to twist it so the 'managers' can feel like they deserve some credit for the project as well, whilst at the same time keeping them discretely out of the way - so that the project itself can move forward smoothly.

    Maybe that is one benefit of shiny new project management tools - it gives the managers something to occupy their time with, so they can keep out of the way.
    • Re: (Score:3, Insightful)

      by Shados (741919)
      Then again, software "coders" are almost never the ones that are responsible for the success or failure of the project -either-. Architects, analysts, team leaders, researchers, etc, are. Actually "building" the thing is completly trivial once these people succeed on their side of things.

      Almost like building a house. Once the plans are drawn, the ressources allocated, etc, if the project is managed correctly, its almost impossible for the coders to screw something up.
    • Re: (Score:3, Insightful)

      by MartinB (51897)

      Projects are successfully delivered by good coders with good tools, and a thorough understanding of the requirements.

      *sigh* I can tell you've either never worked on anything with complexity, or paid attention when you did.

      Right, Mr "I'm so smart, I can fix everything with software development tools". Who does the following for your projects?

      1. Ensures that the *right* people (As opposed to J Random Client Staffmember) make decisions about changes to requirements so they get accepted throughout the pro
    • by gatesvp (957062)

      I hear your anger, but it's CIO magazine, not codeproject.net. You're right, programmers are the actual generators. I have this theory I can "fallacy of management", which is the concept that managers are responsible for project delivery and are therefore "worth more" than the people that "work under them". Managers tend to be good talkers and it's very common to subscribe to the "fallacy of management", so management can actually get away with pretending that they are the most important piece of the projec

  • ... IT management for treating information systems like they are some sort of black magic. Back in the '50s, '60s, etc. The computing folks had everyone convinced that nobody could possibly understand their domain of knowledge. That should have changed once PCs gave the average technically competent person in other fields hands on experience. But the folklore and mystique surrounding IT continues. The other side of this problem is that computer science is just a tool. Its a tool for solving problems and, in
  • A high failure rate could indicate a willingness to take risks and try new things. The fact (at least according to TFA) that the rate of project failures is half the 1994 rate could mean that project management has improved across the industry, but I think it's much more likely that the cause is just a change in the nature of the projects. Project managers in a post-dot-bomb world may be less willing to take risks. At the same time, there now exist best practices for many business-oriented computing tasks w
    • by DaveV1.0 (203135)
      So, in your mind, a CIO who is smart, plans well, and succeeds should be fired for doing his job right and not screwing up, failing, and wasting money.

      Interesting business sense you have there.
  • That's a point that I missed in the fa. In my experience that's one of the most dangerous risks for just about any project. They either have:

    No project sponsor from the business side (usually in high places), or - even worse - there are multiple "sponsors" from multiple departments (usually using the project as a war by proxy entity for their departmental feuds).

    In both situations I wouldn't come near the project with a gas mask and asbstos suit.

  • I'm fairly shocked that "with all the originally specified features" is considered necessary for a project to be considered successful. It's extremely rare for the business needs for a project to be stable over anything more than a few months, which means that for any long-term project the features you deliver _must_ be flexible if your project is actually going to be successful. Couple that with a lack of understanding by users of what they really want/need and going along with original requirements is a

  • What's worse is getting a project done on time and under budget and having nobody notice and nobody care and think it was just normal. But what is even worse, is doing this, then have the 'boss' change their mind and rip the whole thing out behind your back. I work for public schools and have it found it shocking how much this goes on. An example is a 25 computer lab I built in an old classroom that involved computers, tables, wiring, electrical, tables bolted to the floor, new AC, new paint, etc, etc.
  • I've written a small online book [alcohen.com] on my experiences in managing technical projects.

    One of the biggest mistakes I see is that managers don't recognize that there will absolutely be some failures within the project, i.e., approaches that turn out not to work. It's important, when one can, to move high-risk stuff to the beginning of a project, and even have a "pre-project" phase where the unknowns are explored and conquered, leading to a much better spec, and much better time and cost estimates.

    Another

  • What I'm guessing (Score:2, Interesting)

    by mcalwell (669361)
    In 1994, a person of my ability and intelligence would have struggled to write software that delivers. Because so much can be achieved now with scripting languages, standards like XML, and with so much support and documentation available online, so much more can be done more quickly, and be done more transparently, with less intelligence, than in the past.

    I did systems support in a big financial in 1997. Software was written in C++ on Windows. Builds would run overnight. Something wrong? Could be an OS t

  • The whole article reads like a Dilbert cartoon. Metrics and various forms thereof, stupid pithy phrases like "projects do better in a positive environment"...

    Most of the BS these guys are spouting helps them with "peer recognition" but their real workers probably want to hurl, if they even read the article.

    What a crock of shit. There's a few grains of truth hiding underneath all that bullshit, but bring a shovel.

    People care about the project, it'll do well. People don't give a rat's ass about the project

White dwarf seeks red giant for binary relationship.

Working...