Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Programming IT Technology

Is Your Development Project a Sinking Ship? 494

gManZboy writes "Everyone knows that some software development projects succeed and other fail -- the question has always been 'why'? I'm sure we all have our favorite (likely anecdotal) explanations. Well, these guys decided to actually go out there and do a formal survey, and they've got some real data on why projects actually fail (as reported by development project managers -- care to guess where 'changing requirements' ranks?). They've developed a diagnostic formula people can use to gauge the likeliness that the project they're working on right now is (or isn't) going to fail."
This discussion has been archived. No new comments can be posted.

Is Your Development Project a Sinking Ship?

Comments Filter:
  • by fembots ( 753724 ) on Tuesday January 04, 2005 @04:31PM (#11257219) Homepage
    I used to blame "constant client requirement changes" for failed projects as suggested by my project manager.

    Later I realized, as suggested by the senior management, that a good project manager should not let that happen had he properly designed and managed the project.

    Recently I started to think that maybe all failed projects are due to the delays inevitably imposed by the senior management who requires many policies/protocols/documents/approvals/discussions before signing off the budget.

    These delays introduce deadline pressure to project manager, and allow too much time for client to ponder about other features, and most importantly, give breathing space for competitors to come up with similar products BEFORE we do.
    • by Anonymous Coward on Tuesday January 04, 2005 @04:36PM (#11257289)
      Flexibility to meet changing requirements is a good thing.

      All too often, some sales guy will toss in a requirement like "must run on Win98"; and thousands of man hours will be wasted trying to meet something that wasn't even important to the customer.

      If the original spec calls for "turn lead into gold", it's a very good thing if the requirements can evolve as technical issues are identified.

      • Traceability (Score:5, Interesting)

        by persaud ( 304710 ) on Tuesday January 04, 2005 @05:20PM (#11257817)
        One result of ad-hoc software design and implementation has been government regulation of software in the financial, security and pharmaceutical sectors.

        One result of government regulation has been the emergence of requirements management tools like Borland's CaliberRM and Telelogic's DOORS.

        These tools trace every functional requirement back to a business requirement. They also track the risk (schedule, safety, robustness, performance) of every functional requirement to the rest of the system.

        Vague specification, like vague design is an indicator of not understanding the problem. The first step towards understanding the problem is categorization of ignorance, such as unexpected consequences already experienced by the project.

        Good requirements management tools incorporate practices that have been proven to flush out vague specifications. Good traceability educates upstream participants so they can produce better specs in the future. Better specs yield better products, including better spec management tools
        • Vague specification, like vague design is an indicator of not understanding the problem.

          It may also be that the market is not completely understood and, as such, neither is the solution. If you can say you completely understand any market, you are a better man than I. Or maybe you have the luxury of ignoring your market.

          Bottom line, I believe that there is a certain amount of understanding beyond which trying to understand the problem further is wasted effort. This point is reached far before the amount

      • by jeillah ( 147690 ) on Tuesday January 04, 2005 @05:23PM (#11257863)
        Most products specs I've seen lately are what I call CYA specs. They ask for things that are comprehensive enough to keep the blame away from the analyst even if the requirement is for things that are difficult to implement and probably never used by the end user. A prime example of this is requirements for searching and reporting. The spec will call for the ability to search or report on any field or groups of fields, as determined by the user, with multiple search criteria for any field with the data sorted on any field. And it has to be simple enough for a non-technical user to use (no fair making them enter SQL). Chances are it will only make sense for the user to view data in a few ways so why not define these ways and put that in the spec? Nope, cause they might miss something and they'd be shamed for life. Better to just put "I want everything I can think of and might think of in the future" in the spec and complain that the project is behind schedule and is too big and runs too damn slow when (if) it is finally delivered.

        In case you can't tell, I'm in the process of reviewing just such a spec from our legal department right now. Specs written by lawyers are pretty but wordy without really saying what exactly they want...
        • Fork the spec for query building into two sections.

          One where real requirements analysis yields the top ten most valuable and requested queries + report templates. This can be handed off to a designer who creates an efficient and highly usable interface.

          The second spec is for a generic ad-hoc query and reporting mechanism. Since the need is so very generic and so very unpredictable, prudent analysis concludes that a buy solution would be more practical than a build solution. Therefore, buy a generic rep
          • Therefore, buy a generic reporting solution like Crystal Reports to meet the generic needs of the generic spec.

            Using a integrated/seperate application is often not an option. Crystal Reports will often cost more time creating custom reports than just building a tool yourself. I always lie to clients and say "I don't know how to do Crystal Reports" despite doing many more than I would like to remember. Crystal Reports often require a lot of time to do outside a simple report especially when you get into n
        • Funny you should mention specs like that.....I just got done developing a web app that meets just those requirements (except multiple search criteria are limited to AND OR/NOT) for any dataset.

          If you'd like to look at it (I've got no problem sharing code/ideas...I don't work for a corporate outfit) shoot me an email myth @ my homepage minus www.

      • When you get a requirement, you attempt to prioritise it, broadly between show-stoppers and nice to have. The show-stoppers have to be achieved, but perhaps some can be scheduled for 1.1? Nice to haves can always be held over until 1.1 or later.

        Once you have captured requirements, you present them back to the user with some difficulty estimates. This is where the 'Win98' thing you quote should get killed. You also make sure that the customer is aware that you are always thinking around the next releases

    • Later I realized, as suggested by the senior management, that a good project manager should not let that happen had he properly designed and managed the project.

      This cannot be emphasized enough. The project manager needs to not only manage the people within your company and what work they're doing on the project, but also the customer and the customer's expectations.
      • That's great in theory, but if your sales and marketing people aren't willing to cooperate, it can be hard for the project manager who is sometimes dictated to what he can or cannot tell the customer ("we already sold them feature X without asking you, so no, you don't get to tell them that feature X adds two months to the deadline").
    • by Interfacer ( 560564 ) on Tuesday January 04, 2005 @04:44PM (#11257398)
      Not only do client requirements change, but management is also responsible for fubaring things.

      i have been part of a project (past tense) where:
      - management delivered a much too low cost estimate in order to get win the bid.
      - management then expected the project manager and team to meet the deadlines that were doomed in advance.
      - the software design lead designed a behemoth of a framework full of performance and design issues.
      - management did not understand that if you have unexplained system behavior, you cannot say when you will have solved the problem.
      - hardware design was not reviewed, just like software design. this lead to huge problems just before and during acceptance.
      -near the end of the project, more and more people were reassigned to a new project that has the ability to make the department manager look good to the head office. he wants to move up. In effect, succes of the former project became a more and more distant possibility until failure was assured.

      and there are probably some other things that i either forgot or purposly left out (trying to repress memories maybe ;)).
      • Scary! I'd say we must work at the same place, but this pretty describes large software development efforts everywhere.

        Particularly the "framework" bit - this sort of thing is a particular pet hate of mine. Why do people do this kind of thing continually when it almost never works? Why not just solve the direct problem instead? I have seen it over and over again. People seem to miss the obvious point that solving the class of problem is always going to be an order of magnitude (at least) more difficult tha
      • Let me tell you a tale of woe.

        I inherited a project from a consultant who had spent several months (I'm guessing six) doing mostly nothing other than whipping up some mock-ups of how the web pages should look. He read Indian newspapers a lot, pretended to be busy, and did nothing much. When he got caught, he got asked to leave and the project dropped into my lap.

        A new project manager came in, a stubborn old man who was really into old style structured programming. He kept talking about "functional decompo
    • by persaud ( 304710 ) on Tuesday January 04, 2005 @04:46PM (#11257424)
      Release managers can track requirement changes and their impact (effort, schedule) on the project. These changes can be reported separately from the primary schedule, so that everyone can see the impact of scope changes.

      Change is not bad. Adapting to environmental changes (competition, customer education by early prototypes, vendor roadmaps) can make the difference between a one-shot failed project and a multi-generation successful product.

      Big Visible Charts [] is a time-tested technique for non-political status reporting that helps everyone (from senior management to QA) take responsibility for the global impact of local changes. Grab a few unused monitors and create a wall-mounted status display with 1-minute project status updates, you'll be amazed at the results.
      • by Anonymous Coward
        I recently did something similar but web-based. The wall-mounted display wouldn't work in our case since the project is too big and managers have often seperate offices. However everyone has continuesly web access open.

        A SIMPLE status portal page in which you can see REALTIME successful and failed code builds, status of regression systems, resources and 1-click (tm) away usefull info towards the RELATED log files, code changes, problem reports, documentation,...;

        While we have a huge corporate network with
    • Too much "planning and documenting" and not enough prototyping. Whip something up and have the client/user work with it. Make changes based on that. Don't plan the living shit out of it before you even have something to work with.
      • by Mr_Huber ( 160160 ) on Tuesday January 04, 2005 @06:13PM (#11258366) Homepage
        The difficulty here is making absolutely sure the client and the mangement know the difference between a working prototype with canned data and a fully functional application capable of handling real world situations. All to often, I've seen really good prototypes either turn into the actual product, or be the source of unrealistic estimates of project status. (After all, if the demo works, how hard can the rest be?)

        I remember reading an article by Joel Spolsky where he advised to deliberately make the UI for demos less than polished. Make it look like something that was knocked together. Make it too pretty and the client will think you're almost done. After all, to the client, the UI is the app. If that looks done, the guts of the thing must be near done as well.
    • Over design (Score:3, Informative)

      by grahamsz ( 150076 )
      I've seen a lot of projects get truly overdesigned, because someone wants to make sure that they'll be easily extensible to changing requirements.

      The resulting source is then needlessly complicated, and often when it comes to extending it, the original design gets in the way because it didn't pander to the particular change being made.
    • by Linker3000 ( 626634 ) on Tuesday January 04, 2005 @05:12PM (#11257725) Journal
      I used to blame "constant client requirement changes" for failed projects as suggested by my project manager.

      My experience shows this to be quite valid sometimes regardless of how much project control you attempt - a classic scenario goes like this:

      1) The customer is invited to a 'proof of concept' or 'milestone' demo of the proposed system

      2) The customer requests new features or amendments to original spec

      3) The new features are subjected to a cost/benefit analysis by both parties

      4) Customer wants the changes and so the contract clause relating to 'additional or amended requirements' kicks in and a new pricing structure is drawn up.

      5) Customer complains that they are being 'forced into a corner' with the new charges - they want everything completed but aren't willing to pay the extra but feel that if they don't agree you'll walk away from the project

      6) Developers have to decide whether to make the amendments within existing budget, even though it's additional workload, or insist that the customer covers some or (hopefully) all of the charges.

      7) Customer complains and says they won't pay - OR they agree, but you just know that at the end of the contract you'll get a serious amount of grief trying to extract the full and fair cost of the work from the customer.

      8) Customer pulls plug and takes your proposal elsewhere for someone else to work on, or you decide to cut your losses and jump ship anyway.
    • Recently I started to think that maybe all failed projects are due to the delays inevitably imposed by the senior management who requires many policies/protocols/documents/approvals/discussions before signing off the budget.

      So I worked on a project that spent 8 months getting through "project approval" on an 18 month scedule. Of course by the time it was approved, they still wanted it to be delivered in 18 months (from the start date) so we now had 10 months on an 18 month schedule.

      Long story short

  • So... (Score:5, Funny)

    by Blue-Footed Boobie ( 799209 ) on Tuesday January 04, 2005 @04:31PM (#11257227)
    "They've developed a diagnostic formula people can use to gauge the likeliness that the project they're working on right now is (or isn't) going to fail"

    So, if I know it is going to fail, do I still have to try?

  • by Anonymous Coward on Tuesday January 04, 2005 @04:33PM (#11257246)
    Changing requirements is far less bad than a frozen spec based on overanalysis by MBAs who never spoke to customers.
  • Yeah but... (Score:3, Interesting)

    by Anonymous Coward on Tuesday January 04, 2005 @04:33PM (#11257262)
    Are they really getting at why projects fail, or are they just getting a good record of what people on failing projects like to bitch about?

    Changing requirements blah blah blah not my fault blah blah blah...
  • The formula (Score:5, Funny)

    by superpulpsicle ( 533373 ) on Tuesday January 04, 2005 @04:34PM (#11257266)
    Fair management expectations
    + Well allocated budget
    - Patch fixing firedrills
    - unnecessary marketing spinoffs
    + free donuts
    = success

  • I blame perfection (Score:5, Insightful)

    by Anonymous Crowhead ( 577505 ) on Tuesday January 04, 2005 @04:34PM (#11257269)
    People who sit around for months or years trying to design the perfect system. It doesn't exist. Compromise gets projects done.
    • by LazyNerd ( 794850 )
      I've seen a quote attributed to General George Patton that says:

      "A good plan, violently executed today, is better than a perfect plan tomorrow."
    • by expro ( 597113 ) on Tuesday January 04, 2005 @04:53PM (#11257504)

      I have lots of evidence of failed projects due to failure to plan.

      It can take months or years of thought and discussion to reasonably avoid extreme catastrophies.

      While it is silly to try to plan every detail and anyone who claims to do so is lying, a simple elegant, successful general approach is seldom the first one to pop into the head. It takes a lot of thought. Of course, for those incapable of such forethought, why not fail earlier rather than later.

  • by testednegative ( 843833 ) on Tuesday January 04, 2005 @04:36PM (#11257293)
    ... did they fail or succeed?
  • by kevin_conaway ( 585204 ) on Tuesday January 04, 2005 @04:36PM (#11257301) Homepage
    Our project is currently suffering from aggressive scheduling. We are put on too tight of a timeframe to allow even the most minor setbacks. Changing requirements seems to be the nature of the game, and when we dont allot enough time to accomodate these changes, we get into trouble.
    • Remove cloud cover (Score:3, Interesting)

      by persaud ( 304710 )
      Non-minor setbacks are often the result of aggressive scheduling, but cannot always be attributed directly to the specific change or person who initiated the change.

      Look at a schedule as just one component of a (good or bad or in absentia) process. Look at a process as just one component of the product. Then non-vetted schedule changes (aggression without responsibility) become product defects.

      What do you do with defects? You track them. You test for them. You fix them. Data (evidence) is needed for
  • by Ckwop ( 707653 ) * <> on Tuesday January 04, 2005 @04:37PM (#11257304) Homepage
    It's as simple as that unfortuantely - we *never* learn from our mistakes. Over the last thirty years every system we can dream of has been built from nuclear power plant control system to stock market analysis systems.

    Yet we keep playing the buzzword bingo with our new systems, e.g. "Extreme programming", we still keep promise a schedule we can't keep to, we still allow the customer to shift requirement much later in the project than should be allowed, management still don't have enough dialog with the programmers on the ground floor, the list goes on..

    Wake up! We're not special.. the construction industry has been doing huge projects of equal complexity for centuries. Get past your intellectual snobbery and start working together..

    • by Anonymous Coward
      The construction industry has also suffered from slipped schedules and cost overruns for centuries. (Bay bridge, anyone?) The big difference is that with construction it's a little bit more obvious to clients that they just have to keep waiting until it's done.
    • by LWATCDR ( 28044 ) on Tuesday January 04, 2005 @04:51PM (#11257485) Homepage Journal
      "Wake up! We're not special.. the construction industry has been doing huge projects of equal complexity for centuries. Get past your intellectual snobbery and start working together.."

      Umm no they have not. Construction is one of the slowest to change industries on the planet. Take a hotel It is really just room after room. You design one room and then multiply that out to make a floor. Then you stack the floors and you have a building.
      The key is standardized everything. Look at your average home. It is still built out of sticks or concrete blocks. Very little has changed in a very long time. The latest thing is metal studs but it took decades for them to become commonplace in homes. Very little changes and very little in really innovative.
      And if you think that building projects are always on time and on budget.... Ha Ha Ha Ha Ha Ha
      Not on your life.
    • Repeat after me: Software is nothing like Construction.
      • by VeriTea ( 795384 ) on Tuesday January 04, 2005 @05:16PM (#11257769) Journal
        I would repeat after you, but what would I gain by repeating something that isn't true?

        Ok, there is a lot of truth there, but to dismiss the analogy out of hand is to miss some very important lessons. My dad manages large-scale construction projects so I know a little bit about the industry.

        Some lessons that may relate
        1. The team that designs a project is always different from the team that constructs the project. They are seldom even from the same company. The client gets to arbitrate between the two when conflicts come up.

        2. Many projects are extensively estimated after design, but before construction by the constructor (who has much more experience and motivation to accurately assess project costs then the designing company).

        3. Design firms, and construction firms often specialize in very specific types of buildings (i.e. one company may construct only clean-room facilities, another company designs only bridges, etc.). When companies take on specialized projects that they have no institutional experience with, they often fail spectacularly.

        4. The designing company divides the project design documents into known specialties. Metalwork, brickwork, glasswork, electrical work, etc. There are hundreds of catagories, and the design documents break out the project into those standard catagories. When the construction company builds the project, they hire subcontractors to perform work in each specialty. The company that does the glasswork has lots of experience with glasswork. The company doing roofing has lots of experience with roofing, etc.

        5. Changing the design in mid-construction (which always happens) cost big bucks. No exceptions.

        There are more, but I'm bored with this post so I'll stop now.

    • In 90% of the subprojects of construction, a manager can walk by in a few seconds gauge: - progress - quality of work - time to completion - implications to dependent subprojects Can't do that with software.
    • Yet we keep playing the buzzword bingo with our new systems, e.g. "Extreme programming"

      Hang on! The whole point of XP is about the fact that customers change their mind and developers never get it completely perfect in the first draft. XP promises a schedule based on the last one or three week iteration so it inherently remains accurate over time.

      I've been doing XP properly for about 5 years and it's one of the reasons the company i work for has survived. Massive code changes have been neccessary as we've
  • by severoon ( 536737 ) on Tuesday January 04, 2005 @04:37PM (#11257307) Journal

    I've done a lot of thinking about this...I've come to the conclusion that too often, management tries to replace good ol' fashioned thinking with process. It doesn't work. People tend to get focused in on what they're doing to the exclusion of all else, and that means the smart people are cubbyholed and only have half the story and can't see where other parts of the project are failing, and dumb people have free reign over their little part.

    If the ratio of intelligence to complexity is too low, then the project will fail no matter what process is in place or who is managing it. That's all there is to it. There's a lot of cool stuff out there to be done in development...sadly, most of the good ideas will never make it because the people working on them don't use common sense and best practices...they're just not smart enough to see what's important and what isn't.

    This isn't one of those self-important diatribes from a holier-than-thou developer, either...true I'm a developer, but I admit when I'm too dumb to handle the particulars of a project; usually, that means the project is too complex for most people, but they press on anyway. Those projects always go down in flames eventually.

    You have to know what the strenghs and weaknesses of your team and its members are, and exploit those to the fullest. Maybe, then, you can barely accomplish a project if the goal of that project is simple enough.

    • Smart People (Score:2, Insightful)

      by persaud ( 304710 )
      can be used as an excuse to avoid process, which is a distinct animal from bureaucracy.

      Good process is independent of the intelligence of the humans implementing the process.

      Good process amplifies the effectiveness of all participants.

      Good process generates tracking data that can be used in negotiations between development (reality) and management (theory).
    • I utterly agree (Score:3, Insightful)

      by SuperKendall ( 25149 ) *
      I have seen this time and time again, people trying to use Process as a mechanism to put everyone on the same level. It sure works - the people who are normally 10x as effective as others are hamstrung and unable to be effective at what they do.

      This is the real tragedy of Sarbanes-Oxley. It is being used as a trump card for every process flunky that comes down the pike to implement their favorite process to the fullest. This is going to have a real and very unfortunate effect on companies that become t
    • Correct (Score:3, Insightful)

      by sg3000 ( 87992 ) *
      > management tries to replace good ol' fashioned thinking with
      > process

      That's because that's what they teach in business schools. Businesses are about repeatability and consistency. It's good if you can make a cup of coffee. It's great if you can sell a cup of coffee for more than it cost you to make it. If you can make a good cup of coffee and sell it profitably one million times, you have a healthy, sustainable business. Obviously, the third action requires a process.

      That's why sometimes people ma
  • by jacobcaz ( 91509 ) on Tuesday January 04, 2005 @04:38PM (#11257318) Homepage
    Every project, whether it's a development project, implementation or business process engineering, that has failed for us has been because of poor project management. Period.

    We've had people who didn't know how to accurately scope business requirements, get buy in from other departments and generally "play nice" enough to keep everything running smoothly. Your P.M. needs to be able to be a hard ass, but also to be a buddy.

    It boils down to excellent management skills and excellent people skills and without both you're setting a project up for disaster. A good P.M. needs to know when to tell senior management it's asking for the impossible too, and a good P.M. needs to know he has kung-fu so he can get away will telling senior management their idea won't be implemented.

    • The problem is when sales start suffering and things aren't going well on that end of the business, senior management will tell the project manager to stuff it or get fired, and that they have no choice and the customer absolutely can't be told that feature X has too high a time cost to make it into the next release.

      If your project manager is completely constrained, then it's not his fault that he can't push back on poorly defined business requirements or ridiculously unreasonable timelines.

      The solution i
    • Every project, whether it's a development project, implementation or business process engineering, that has failed for us has been because of poor project management. Period.

      Blaming the project manager is a cop-out. It's like saying a plane crashed because of "pilot error." Yes, probably the pilot made an error, but he certainly didn't intend to crash the plane (terrorists excepted). To understand the problem well enough to fix it, you need to go deeper. What is there about the system that caused the

        • What is there about the system that caused the project manager to make poor decisions?

        Well, in several cases it was upper management not having a methodology for selecting a qualified project manager; thus putting the wrong person in charge of the project where it promptly fell on its face.

        Everything got much better when that person unexpectedly quit and walked out. A bit of panic and frenzy and then things smoothed out quite nicely.

        So if you don't have both a top-down and bottom-up methodology for

  • Cosmo Quiz (Score:5, Funny)

    by brw215 ( 601732 ) on Tuesday January 04, 2005 @04:38PM (#11257321) Homepage
    Is this simply the nerd version of the ages-old cosmo quiz? I fail to see how "The one-minute risk assessment" is any more comprehensive or meaningful than the "Does he think you are fat"-type quizes that make their way through women's magazines.
  • I can't believe how many buzzwords they managed to fit in there. You don't have problems their Risk Drivers, don't we already have enough Jargon?
  • by ag4vr ( 705570 ) on Tuesday January 04, 2005 @04:39PM (#11257340)
    One key element that appears to be missing is the qualifications of the manager or management team. Project management is a different skill set from design or development.

    It's not to say that a good designer or developer cannot be a good project manager; it's just a different job, like asking a plumber to rewire your house.

  • by TheFairElf ( 669537 ) on Tuesday January 04, 2005 @04:44PM (#11257403)
    The client I'm currently working for has a core product that is modified as per each customer's requirements. The modification process works exactly like this:
    if (customerName == "cust1"){

    // customizations for customer 1
    }else if (customerName == "cust2"){...
    .. and so on. There's a new customer? Easy, add another if statement. The entire code base is a hodgepodge of conditional statements. Needless to say, the program has tons of bugs and the performance sucks. Its a wonder to me that the customers put up with it and even continue to pay for it.
  • by Kenja ( 541830 ) on Tuesday January 04, 2005 @04:45PM (#11257410)
    No, what I want to know is where "linking your project to a slash dot article" ranks.
  • by Anonymous Coward on Tuesday January 04, 2005 @04:50PM (#11257475)
    It ALWAYS comes down to people. This article looks to be a discussion relevant more to a commercial environment than an open source one, but I guess the same fundamental principle is true - without the right people you will not succeed. This means competent and motivated technical people, clueful and skilled management, and customers willing to be reasonable and pay for what they are getting. Take away any one of these elements, and there is no technique in the world which will result in something everybody can define as a success.

    These guys break down the problems into useful categories, which will be helpful for good teams who want to know how to be more efficient. But for my money a group of serious, decidated people who honestly want to get the job done and do it well will usually get there, barring external factors beyond their control messing it up. It might take a while, cost $$, etc. but they'll make it, because they WANT to.

    Many (I would even say most) successful open source projects succeed because they have one or several individuals willing to put the work in to make something happen. The tools they use or the way they work are less important than determination to get it done and do it well. Those without that wither on the vine.

    In theory, commercial companies and development teams should be motivated by the $$ they are paid, but that doesn't always translate into doing the job well. There are PHBs, lazy workers, unreasonable customers, and all the other joys of life out there. There is no magical "business formula" which can transmute this combination into a good product.

    Don't get me wrong, project management and efficiency techniques are a very good thing, but only when you've got the people to make good use of them.
  • by smooth wombat ( 796938 ) on Tuesday January 04, 2005 @04:52PM (#11257496) Journal
    is to develop a sinking ship, isn't that another name for a submarine?
  • by Neurowiz ( 18899 ) on Tuesday January 04, 2005 @04:52PM (#11257502)
    ... since 1994, the Standish Group has been publishing the results and reasons of IT projects. Go here for the original report. []

    We've gone from about 25% of projects being "successful" (on time, on budget, meeting stated needs) to about 31%. So translated, that means 2/3ds of the time you get into your car or get on an elevator, it'll work as you want.

    Consistently, the top reasons for projects failing, for the past 10 years?
    1. Unclear, poor requirements
    2. Lack of user involvement
    3. Lack of buy-in and support by upper management

    I have to agree with other comments made, this isn't rocket science. We just need some time and maturity as an industry. Civil and mechanical engineering have had thousands of years to work out their kinks. The software engineering science has had to deal with technology and implementation far outpacing our understanding of the basics and principles involved.

    But we're getting better.

    Honestly, if the world at large knew how brittle, fragile and reliant on heroism most of the critical financial and industrial software was, there would be a huge outcry. It's one of the shameful aspects of our industry.
  • It's not magical (Score:5, Interesting)

    by beldraen ( 94534 ) <> on Tuesday January 04, 2005 @04:57PM (#11257549)
    Having many years of successful software project management under my belt, I can tell you it boils down to two concepts: professional training and discipline.

    There are a million and one books and surveys and they all say the same thing. First, there is a formal process for the development of anything (not just software). This starts with the formal documentation process and meetings to discover functional and non-functional issues. Second, there is a very strong sense by everyone to want to adjust it a little more. From senior managers who allow scope creap to managers who want steps to be cut to make up time to programmers constantly who rewrite the code because they think they can squeeze 5% more time out of a loop that runs for less than a second in a process.

    Most people do not realize that in a successful formal process that the actual time in a software project that is used to build the software should amount to only about 30% of the project's development time. The other 70% is time spent on documentation, meetings, and testing to ensure that the 30% of time used on software delevopement is actually what the company is needing. And, it is discipline that keeps people on the project process in the face of the fear of not getting the project done right. The process has to be allowed to work, both to reach a project end point and to have unobstructed process from which to learn.

    The part I get a kick out of is that just because people write software or run a company that they somehow think they just ought to know why projects work. If complex systems were just so easy, why would we need formal training? After all, anyone can build a bridge successfully without training, right? I am not being hard on people, though. I had this exact same though years ago and what I figured out is that the vast majority of the software industry is so poorly trained that it doesn't even realize that it poorly trained.

    Successful software development books have been around for more than 30 years. Go read! Better than that, get a university degree. The more liberal the better. Honestly, it is worth it. Here is a good place to start: Systems Analysis and Design by Kendall and Kendall (ISBN 0-13-041571-5)
  • In my experience, the quality of the software that's implimented is the biggest cause of success or failure. If we build from scratch (or using open source), we can almost always pull a failing system out of the fire by throwing a few more quality development and analysis hours at it. If we buy good quality software to impliment, it works about the same. If we buy terrible software and try to impliment it, no amount of time or money can save us.

    A number of times we've had a software buying decision from a

  • Before someone can finally admit they were part of a team of fuckwits who promised way more than they could actually deliver and so kicked off the cycle of overexpectation?
  • Please check my math (Score:3, Interesting)

    by Spackler ( 223562 ) on Tuesday January 04, 2005 @05:00PM (#11257587) Journal
    Ok, I did RTFA (for once).

    Quote1: nearly $1 trillion was wagered on underperforming projects

    Quote2: A large number of underperforming projects ultimately fail

    Quote3: costing U.S. companies more than $75 billion each year

    How does 7% failure become a "large number" of projects failing?
    I would expect 7% to fail just from bad ideas alone.

    A little gloom and doom?
  • by glh ( 14273 ) on Tuesday January 04, 2005 @05:02PM (#11257604) Homepage Journal
    I find it interesting that "methodology" was the biggest risk driver for a project.

    I think the true crux of the problem with software development lies in understanding requirements. A methodology will most definitely HELP find the requirements, but I don't think it's directly the biggest risk driver.

    In my experience the biggest problem is getting the users engaged in the requirements gathering. This is the most critical piece- no matter what methdology you use (and they will come and go) you still need to make sure that you understand the requirements. In most business environments, software development tends to a discovery process. In some cases the users can visualize a system and what it should look like, in others they cannot and it just may take a lot longer time. In that case, expectations should be properly managed by the stakeholders. PM's come in to play and should explain what is likely to happen- requirements will change, development or design may take more time, etc. Investigate other options for requirements gathering and understand not all of it may be able to be done on paper.

    I've found that most business applications work best when I have users who have had some level of experience with Information Systems, who are committed to walking through what the system should do, and have support from management to do so through the entire development cycle. Technology and development tools are usually the issue, especially if you have competent developers.

  • by dj42 ( 765300 ) * on Tuesday January 04, 2005 @05:03PM (#11257616) Journal
    In my experience, it is usually drugs, alcohol, too much sleep, unconcerned management, or a combination thereof that causes projects to fail. Have you ever tried to project-manage after 8 double vodkas, a short nap, and a full rack of ribs?
  • It's because of poor project managers who don't fully understand the project and the marketing departments that want to change the scope of the project every 15 minutes. Much to the point that a project that had 4 months of work completed and the original project was within a few hours of being 100% completed that it ended up being outsource and later scrapped completely. Read some Dilbert [] comics, marketing departments can mess things up hardcore sometimes.
  • by museumpeace ( 735109 ) on Tuesday January 04, 2005 @05:05PM (#11257638) Journal
    I'll suggest everybody who has not yet done so should RTF precedents for such a is as ancient as it is true: Brooks "Mythical Man Month" [] describes the reasons projects blow up pretty well. For all the technology heaped on software development in the 30 years since the book came out, very little has changed: Software projects are complicated beasts attempted by mere humans. Steve McConnel's books [] will be more familiar to /. readers and his approach to project management tries to head off the "changed requirements" fiascos with a feedback and correction mechanism of frequent critical project reviews...I wonder if that actually has worked for anyone:-(
  • by Badgerman ( 19207 ) on Tuesday January 04, 2005 @05:11PM (#11257709)
    Interesting article. I can't disagree with its findings, though I'd argue they're of limited usefulness as the problems it notes can happen under a variety of situations.

    The most unexpected result here, and the most insightful to me, is "Similarity to Previous Projects." This is a factor that I think deserves more attention - you can have a great staff, great management, and all the resources, but stick them in unfamiliar territory and your chance of failure goes up.

    I don't think people pay enough attention to this factor, and thus it sneaks up on them easier than the obvious ones.

    I have witnessed very talented people completely screw up an simple application because they had no previous experience with a project of that particular kind and neither did the management structure. Thus they all did their best, worked hard - and still produced a massively flawed product.

    In these cases, I asked myself "How could they mess up like this when the solution was obvious." Now I realize that the solutions were obvious to me as I was more familiar with the kind of software they were trying to design.

  • Lack of focus (Score:3, Interesting)

    by jmichaelg ( 148257 ) on Tuesday January 04, 2005 @05:13PM (#11257730) Journal
    The projects I've seen go down the tubes tended to be poorly focused. Conversely, the successful ones had a set of clearly stated goals and you could see how a particular piece of code was designed to move towards that goal.

    The lack of focus made testing difficult because it wasn't particularly clear what the testing metrics should be. A library system I know of was so overwhelmingly bloated trying to meet a variety of interoperability specs that when the testers saw some 2 megabytes of data cross the lan to handle a single checkout/checkin transaction, they didn't realize they had a problem.

    Another salient feature of successful projects I've worked on is technical competence. The managers of the successful projects tended to be ex-coders and had a feel for what made sense vs what didn't. The bloated projects were run by people from all manner of backgrounds and hence, didn't have the cut-to-the-quick feel when something was going awry. One time, I was working on an air defense project for a country in the middle east and the project manager started getting antsy when he saw all his developers waiting on the compiler. We were using the machine we were going to deliver the product on and it was having a tough time just compiling code for some 12 developers. He sat down and wrote a bare-bones air defense system that did nothing more than establish a client server relationship and had the client simulate the required number of radar contacts per second while the server did nothing more than ack said contacts. The machine couldn't handle a load as simple as that which led to some back and forth with the hardware company until they upgraded the hardware to handle the problem. Had he not had the tech background, he wouldn't have realized that there was a problem until it was too late.

    The number of projects failing now will probably rise because Moore's Law isn't there anymore to bail over-speced projects out. The code written today won't run any better on tomorrow's machines primarily because it doesn't look like tomorrow's machines are going to be much faster. Knocking that crutch out from underneath projects will tumble more than a few projects.

  • by kpharmer ( 452893 ) * on Tuesday January 04, 2005 @05:15PM (#11257754)
    Most project management methods push waterfall development - with its huge reliance on time-consuming and error-prone upfront analysis & requirements gathering.

    Of course, they hate requirements changes. And of course, their initial requirements are usually wrong - and fail to meet the need.

    The answer isn't to stop changes - but to use methods that aren't so vulnerable to impact of change - like patterns, agile methods, passionate & highly skilled staff, etc, etc.

  • by grassy_knoll ( 412409 ) on Tuesday January 04, 2005 @05:16PM (#11257766) Homepage
    Our most famous crash and burn ( to date ) was an attempt to migrate a number of different applications to an Oracle Applications suite.

    We expected a web based desktop client wouldn't require configuration; a jinitiator component required numerous desktop visits.

    We expected streamlined operation; In fact the replacement product required more end user data entry and provided less critical information ( i.e. fewer metrics the end users have come to expect).

    Management drank the marketroids cool aid. They should have asked the end users to evaluate the software before commiting to a purchase, rather than shoehorning the end users into accepting what was the cheapest.
  • by capsteve ( 4595 ) on Tuesday January 04, 2005 @05:17PM (#11257778) Homepage Journal
    i actually was "assigned" to supervise a death march project at my last employer. my "new" manager(6th one in one year) knew the project was going to be canned(didn't confirm the inevitable to me, even when confronted), and most of the people would be absorbed into other projects or simply layed off. why was it a doomed project? politics.

    someone else in our organization (at another geographical location), happened to be better aligned with the top management group, and used this to their advantage to eliminate competing projects, or in some cases eliminate the internal competition and take the projects over as their own.

    of course at the time i had no idea what i was getting into(or who my "competition" was). no matter what our team did to produce a superior product, our project was cancelled for reasons beyond our control. i ended up stressing out and nearly damaged my health and my relationship...

    then i read a book call Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects. i soon realized that we were set up as an ugly style project, doomed(in fact designed) to fail.

    it's good to understand why projects fail, i have not yet RTFA, but i'm sure it will compliment some of the discussions/concepts in the death march book. good read.
  • by Bootsy Collins ( 549938 ) on Tuesday January 04, 2005 @05:54PM (#11258160)

    It would be interesting to see such an analysis done with an open source-centric viewpoint: why open source/free software projects fail.

    It would be necessary to structure the survey carefully to avoid the obvious results that don't contain useful information. For instance, Sourceforge is littered with old projects that never got past alpha or pre-alpha because no one was interested except for the project initiator (who never created enough of a start to encourage significant involvement from others), and the project initiator eventually lost interest him/herself. That may be the way in which most open source projects fail -- but that knowledge is of little use to someone running a project and looking for tips on management. There are of course books about aspects of this topic; but it would be nice if someone were to do a similar survey of open source projects that did get their legs underneath them, that did produce something that enticed involvement and an interested user community, only to eventually fail.

  • by archilocus ( 715776 ) on Tuesday January 04, 2005 @05:55PM (#11258170) Homepage

    I'm working for a large Telco doing roughly 80-120 IT projects every calendar year worth about $200M. Most of them get through in one way or another, but some fail spetacularly and all of them have ridiculous overheads, delays and frustrations.

    Best example of a crash-and-burn is a transaction engine designed to process a simple text file from another company. Should have been 6 months/$500K, project actually folded at 2 years / $3M and now we're going round for a second bite at the cherry (but with a new project name!!!).

    Why do they fail ? Lot's of reasons.

    Sometimes the user's requirements are unclear. Sometimes we're using the wrong spanner for the job. Sometimes the team loses the plot and we get a jumbo jet when we wanted a paper air plane. And we're always under pressure on time, but that's business - if we don't get there first someone else will.

    What's the root cause?

    Complexity. We let our systems get too complex and now a two line code change can cost >$500K because the down stream effects will hit ten other systems that generate $1M/day of revenue.

    The moral - KISS. Use the simplest solution for the job. Don't let the sales guy run away with it, don't let your geek-ego run away with it, don't let the user's get over excited and your project might just come in on time on budget. As someone else said... it isn't rocket science... or shouldn't be...

  • After I RTFAed... (Score:5, Insightful)

    by Eneff ( 96967 ) on Tuesday January 04, 2005 @05:57PM (#11258191)
    Thanks mirrordot! []

    Tiwana and Keil were asking MIS directors what *they* thought, not project managers or developers, leading me to believe that this is more based on client perception than someone with experience working on said projects.

    That said, they ranked changing requirements last when talking about risk of failure, and actually said that inappropriate methodology was the top reason of project failure.

    Now, while a lack of any sort of methodology is a disaster waiting to happen, I have a difficult time believing that a bad fit for a project creates more risk than project complexity and shifting requirements combined, as they suggest.


    Do you really believe that a client is going to place shifting requirements as a risk? After all, they're the ones asking for the changes!
  • by Titusdot Groan ( 468949 ) on Tuesday January 04, 2005 @06:03PM (#11258269) Journal
    The Software Project Survival Guide [] has an excellent self survey to gauge the current risk of your project failing. It's a lot more detailed than this "survey" and includes things like having a top ten risks list and management support.

    It's written by Steve C McConnell (who also wrote Rapid Development [] and Writing Solid Code []) and well worth it for anybody doing project management.

  • by Ann Elk ( 668880 ) on Tuesday January 04, 2005 @06:07PM (#11258301)

    Chris Peters (former Microsoft VP) wrote an interesting documented called "Is Your Project Out of Control". It seems to have appeared on the net in various [] formats [].

  • Mmm. (Score:3, Insightful)

    by mwillems ( 266506 ) on Tuesday January 04, 2005 @07:30PM (#11259070) Homepage
    Well, maybe as an engineer as well as a senior manager and a CTO, I can add my two cents' worth.

    First, a survey based on data "as reported by development project managers" is suspect to a high degree. Obviously their view will differ from that of the senior manager and from the actual developer. SO I will put little stock in that survey.

    But the question is valid: why does it always fail?

    Personally, I see a mixture of the following:

    • Management lack of technical knowledge, or "How can you ask someone to manage a development project when that person is the sort of person who does not even know how Excel works?" This leads, of course, to wildly unrealistic expectations: which is the prime cause of failure. The emperor has no clothes and spending 100k on Siebel will not make your company suddenly efficient!
    • Developer lack of discipline - a real biggie. "We do not need to write specs, that does not apply to us: we need to design it as we go", how often have I heard that, as well as "Hey, even MS is always late so we're not doing badly only being 6 months late". There's also Blaming Others: "if you had not asked us to also fill in time sheets/come to a company meeting/etc we'd have been on time".
    • Developer lack of business understanding. The world is complex and guess what, it ain't ideal. Success in business is about being somewhat less inefficient than the competitor. It's not about being left alone for six months in a clean environment without intrusion.
    • Lack of specs (which leads to mission creep immediately), or overanalysed specs: both of these kill a a project quickly.
    • Lack of process around implementation and testing. Sorry - you do need progress reports, test sequences, checklists, code reviews, etc.

    I am not ranking them in importance, will leave that to others!


  • Bias (Score:3, Interesting)

    by Bloater ( 12932 ) on Tuesday January 04, 2005 @07:57PM (#11259292) Homepage Journal
    Interesting that project managers say the factors that they are paid to manage are the ones that are most important and higher risk (and thus justify the most funding, of course).

    I also think that the chosen dimensions are not orthogonal. The methodology chosen is influenced by experience with similar projects... If your architects have done something similar before, then a structured approach will be extremely effective, if they haven't, then an iterative approach as they work out how to do it.

    All in all, a pointless study that will do more harm than good.
  • Bad Idea? (Score:3, Interesting)

    by daVinci1980 ( 73174 ) on Tuesday January 04, 2005 @08:30PM (#11259561) Homepage
    I find it funny that they didn't consider 'fundamentally a worhtless idea' one of the top reasons that projects fail.

    Seriosuly, how many of you have worked on a project (probably you were assigned by someone who wanted to get rid of you), where you thought from the beginning of the project 'this is a terrible product?'

    Even if the product ships (which is unlikely, because your coworkers probably also think the product is terrible, thus morale plummets, thus productivity plummets, thus ...), the customer won't want it, and won't buy it.

User hostile.