Waste In Software Projects

Waste In Software Projects

This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman.  In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used.  The question this evening was, for the 45% of the features that were never used, what was the cost incurred?  Well, I can tell you it’s probably a lot more than 45% of the budget!  What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment.  If a feature or product is never used, it’s waste. But, since XP2002, have we learned our lessons?    Standish Group Study

Are we still delivering features that customers will never use?  I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc.  The collection of data was just a distraction from the actual blog post.  Thank you to those to participated.

9 Replies to “Waste In Software Projects”

  1. Derek, I find it difficult to give any credence to information coming out of the Standish Group without carefully examining their definitions and the method used to obtain their information. Do you happen to have a soft copy of the actual report (relevant to the point made in your post) or a known link referencing it?

    Cheers, shim.

    1. Shim, per Martin Fowler,, who was there at the conference, Jim Johnson actually quoted two studies.

      “a DuPont study quoted only 25% of a system’s features were really needed. A Standish study found that 45% of features were never used and only 20% of features were used often or always.”

      That being said, the study in question could be from the CHAOS Chronicles, comprising 12 years of research, done through focus groups, in-depth surveys and executive interviews, on project performance of over 50,000 completed IT projects. I can’t find any one specific source to provide you.

      I am NOT saying this chart reflected reality of feature usage at the time it was presented. I was referencing it as a chart that I regularly see referenced, to begin the conversation.

      Good to hear from you,

      1. Thanks Derek,

        I’m a real sceptic when it comes to the Standish Group’s reports. The professional literature is full of critical analysis of their findings so I won’t take the time and space to elaborate on it here. I am aware that Agile proponents are excited at using such stat’s to promote the Agile cause. I wish this was not the case as Agile can be promoted based on its own merits without needing to rely on other irrelevant arguments (especially when these are grounded on unsubstantiated data.

        Cheers, Shim.

        1. Shim, I agree. I wish there was more literature from PMI or some other more reputable source that we could leverage. But we all seem challenged to even agree how “success” or “failure” is defined. I won’t be paying Standish Group to get access to their reports. Rather, to head in a better direction, I’ve started to incorporate data from the (free) annual VersionOne survey.

  2. Glen,
    I’m not saying I agree with Standish findings or even how they define “success” or “failure”. I’m merely using the chart to spark a conversation.

    I think I succeeded in doing that. Thanks for the comment. I hope my readers find it useful.


  3. Dave, from what I have read, I don’t agree with the Standish definition of “Success” or “Failure”. The analogy I would use, in respect to your comment is, I pay for life insurance monthly but I sure hope it’s a long time before I use it! It doesn’t make it any less valuable. That value just hasn’t been realized yet.

    But, I still can’t help but use the chart to spark a conversation and I think it worked. I’m happy you added your perspective. It will give my readers more to think about. I think it’s important for the conversation to happen. I think it’s important for us to question.

    Great to hear from you,

  4. I remember, I developed an enahancement long time back that took 200+ hours to develop, was business critical and was deployed as soon as it was developed. Later, I found that that feature was used only a couple of times by the Business Analyst who wrote the requirement. This enhancement met this fate because the higher management person from the region who requested this enhancement moved to another department and no one else knew about this feature. I think an enhancement which does not have sufficient stakeholders and probably less communication may meet this fate. I have written an article (Basic Tricks to successfully execute a project) on web type of communication which can be very effective in most of the situation.

Leave a Reply

Your email address will not be published. Required fields are marked *