Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


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

  • 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.
  • by Neil Blender ( 555885 ) <neilblender@gmail.com> on Tuesday January 04, 2005 @04:44PM (#11257396)
    When your project manager hands you a project started by a rookie and tells you, "It's 95% done. All you have to do is the final touches."

    That usually means the UI isn't done. Unfortunately, the UI consists of 905% of the remaining work.
  • 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.
  • Re:Sigh. (Score:2, Interesting)

    by Neurowiz ( 18899 ) on Tuesday January 04, 2005 @04:47PM (#11257437)
    You should be doing that anyway.

    An estimate is done based on assumptions and scope. If your client changes the scope, that should cash in your pocket the moment they say "Yes" to the proposed change and resultant cost.

    Part of my job is process improvement. One of the first things I find useful to teach development teams is how to say "No" or "It'll cost this much and take this long. Do you still want it?"

  • by LazyNerd ( 794850 ) on Tuesday January 04, 2005 @04:50PM (#11257468)
    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 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.
  • 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. [standishgroup.com]

    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.
  • by Fnkmaster ( 89084 ) * on Tuesday January 04, 2005 @04:53PM (#11257511)
    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 is your sales team needs to buy-in to the idea of properly qualifying customers and setting expectations reasonably, or not setting expectations at all until project management has been brought into the sales process. The "lie, cheat, do anything to close the deal" technique often fucks small companies over leaving these disastrous projects in its wake. And yes, bad project management, poorly defined requirements or changing requirements and other factors can certainly ruin a project too.
  • It's not magical (Score:5, Interesting)

    by beldraen ( 94534 ) <chad.montplaisirNO@SPAMgmail.com> 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)
  • Remove cloud cover (Score:3, Interesting)

    by persaud ( 304710 ) on Tuesday January 04, 2005 @05:00PM (#11257581)
    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 tracking, testing and fixing schedule defects. Collect the data in advance so you can fix the schedule in retrospect.

    Otherwise, every day will be Groundhog Day.
  • 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 Anonymous Coward on Tuesday January 04, 2005 @05:09PM (#11257681)
    We start with unrealistic schedule (READ: what have management been smoking?) leads to short cuts (READ: code it first, worry later) compound it with requirement changes (READ: customer doesn't know what it wants) then wrap the whole thing up with zillions and zillions of bugs that are difficult to fix (READ: short cuts that had to be paid sooner or later...)

    In the end what management estimate would take six months (which engineering insist can't be done in less than a year) took a year and a half, and is entirely unmaintainable.

    A cow-orker uses the bulldozer metaphore to describe our project(s); every short cut we take is like dirt collecting in front of the bulldozer. At some point we either need a bigger bulldozer or we start from scratch...
  • 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 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.
  • 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
  • by YU Nicks NE Way ( 129084 ) on Tuesday January 04, 2005 @05:24PM (#11257872)
    You might want to read the ACM discussion. They did a factor analysis on the basis of scalar responses very similar to the Standish study. Their results basically show that the CHAOS study is nonsense.
  • by Ansonmont ( 170786 ) on Tuesday January 04, 2005 @05:25PM (#11257882)
    Really? Are you kidding? Architecture and construction are NOT standardized. Parts of it are standardized, but people are using different materials, designs, etc all the time. Not everyone lives in row houses, mcmansions or big apartments.

    Just because architects made big blocks of apartments that were the same does not mean you can't make a little house made of foam and popsicle sticks that no one else has ever thought of.

    The analogy to software is a good one, as you have very different projects in size and scope. The main difference that everyone points out is that you can sort of see how much more a building needs, but software can be "99% done" forever and you can't really know when you will be ready until you are.

    Anyway, my 2 cents.

  • by fyrie ( 604735 ) on Tuesday January 04, 2005 @05:34PM (#11257974)
    Here is a pretty good paper by Mary Shaw explaining why software is not yet an engineering discipline (IEEE). http://www.sce.carleton.ca/faculty/ajila/4106-5006 /Prospect%20Eng%20Soft.pdf/ [carleton.ca]
  • by XMyth ( 266414 ) on Tuesday January 04, 2005 @05:42PM (#11258049) Homepage
    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 only...no 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.

  • 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 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 [stanford.edu] formats [brightwork.com].

  • by cavemanf16 ( 303184 ) on Tuesday January 04, 2005 @06:22PM (#11258445) Homepage Journal
    Ah, but you're viewing the "what constitutes software development project failures" through a developer's looking glass. The goal in analysis is to be objective in determining what the true "drivers" are behind the data. In this instance, I don't think the report is wrong. True, user requirements (and understanding them properly) may be your biggest headache, but overall I find it is the methodology driving failed software projects at the company I work at currently. Usually the projects are never complete failures, but sometimes they are very behind schedule, don't work the way the end users thought it would, and generally are not really what the user wanted in the first place.

    And I think the reasons for these psuedo-failures is directly due to methodology. Developers think users will just "do it the right way", when software testers and business people are telling them that they won't. But the developers, those all-knowing gods and godesses of everything technical, come up with 5 major reasons why "well it would take a LOT longer to code that! I guess we can't deliver the product to you then..." This twists the arm of the business who NEEDS that software app to be delivered on time.

    If the methodology of software programming were different, and developers actually talked to "users," and worked with (instead of against) software testing groups, business analysis groups, and senior management the failures would happen with much less frequency.
  • by Open Council ( 704163 ) on Tuesday January 04, 2005 @07:18PM (#11258949) Homepage
    In the days of 4-GLs I prototyped a number of Ingres apps. As well as learning to produce not-so-pretty prototypes, I also used QUEL as the query languge. Once they had agreed the basic functionality i could mention that it used the "non-standard" QUEL rather than SQL. "Oh you'll have to change that" they'd say, giving me an excuse to throw away the prototype and start again for the real app.

    Sadly QUEL was far better than SQL.
  • my experience (Score:1, Interesting)

    by Anonymous Coward on Tuesday January 04, 2005 @07:26PM (#11259033)
    I've worked on many software projects over the last few years. Here were points of failure:

    1. No source code control. Particularly a problem if there is one key engineer holding things up.

    2. Your in a start up company. The sales and marketing departments in your company make a deal with a large customer. The customer changes the requirements on a weekly basis. The changes result in practically a new product being created. Later, you find out that the important customer is not paying a single dime for the project. They a jerking your chain. In fact, they might be mining info out of your company.

    3. The project manager does not know jack. A paper pusher but knows the lingo. e.g.. "flow", "process", "milestone","power point".

    4. Too many consultants or third parties involved. They don't want the project to end because it means no more $$$.

    5. Mergers in service companies. Typically there is hacked code on a back end nobody has ever seen. The managers want to create one system. You get a hodge podge of incompatibility.

    6. Lack of documentation and specs. Nobody even knows what to build or how to update/merge the systems.

    OK, thats my 2 cents.
  • 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.
  • Re:Traceability (Score:2, Interesting)

    by persaud ( 304710 ) on Tuesday January 04, 2005 @08:39PM (#11259626)
    Well perhaps the flimsy houses just never made it out the gate. The article is supposed to be about why projects fail. A failed project in my mind never shipped, and therefore, unless you worked there, you didn't know about it.
    Well, Linux is open and the history is available for all to see. Both Google and Yahoo have been the subject of various articles on their internal architecture. Yahoo in particular is a good example of ad-hoc requirements and incremental implementation. They used a heavily customized version of FreeBSD and a proprietary scripting language (since replaced by PHP). Google as we know used a heavily customized version of Linux. I attended a UC Berkeley presentation by a senior Yahoo scientist who said they could go from internal concept to initial public deployment in two weeks. Google Labs shares a similar philosophy. In these particular cases, the development cultures promote early prototyping, so "not shipping" isn't the failure criterion it may be elsewhere.
  • History and Future (Score:3, Interesting)

    by persaud ( 304710 ) on Wednesday January 05, 2005 @07:17AM (#11262298)
    Appreciate the history lesson. Are any of the early requirements management tools still around, in any incarnation?

    Agree on the value of tracking estimates and actuals. I've not had the experience of working on a project that was mature enough to track both. But even a mental comparison of estimates with personal observation was invaluable in understanding developer strengths/weaknesses.

    Do you think there is a place in the market for an open-source requirements management system? E.g. if someone started such a tool, would any home-grown tool owners contribute expertise or code?

    Have you seen a good tool that is more affordable than CaliberRM/DOORS? The market seems to have an absent low end (excluding MS Office). Microsoft plans some process management for their developer tools, e.g. "Visual Studio Team System" is mentioned in a comprehensive description (with photos) [msdn.com] of their internal build+test environment for ASP.NET.

The primary function of the design engineer is to make things difficult for the fabricator and impossible for the serviceman.