The Institute of Electrical and Electronics Engineers (IEEE) did a study in 2005 that examined large software project failures (in the multimillion and billion dollar range)\u00a0 to try and figure out what they had in common. Here are a few facts sobering distilled from that report:<\/p>\n

\n
• $1 TRILLION spent worldwide on hardware, software and services<\/li>\n
• 5 to 15% of IT projects are abandoned before or shortly after delivery<\/li>\n
• Companies budget 4-5% of annual revenue to IT projects (including software and hardware)<\/li>\n
• IT companies budget 10%<\/li>\n<\/ul>\n

  In other words, as much as 15% of all money spent on custom software development is wasted because the projects never fledge. That’s staggering. If we cut the 5-15% figure down the middle and say that only 10% of projects fail, we\u2019re still talking about $100 billion dollars wasted annually.<\/p>\n

  <\/p>\n

  These figures are for in-house projects. Consultant projects don’t fare as well. Those projects have a 15-62% success rate. Also the larger a project is, the higher its risk for failure. Larger projects fail 3-5 times as often as smaller projects. That’s because it’s harder to spec, build, and test a large project.<\/p>\n

  And as any developer knows, software is inherently fragile. You can have perfect schema, beautiful layouts, and well-thought out processes, but a single bug can cause a critical script to fail. Programmers typically spend 40-50% of their time reworking processes to fix bugs instead of creating new, value-added features. Bugs or errors that make it into a launched product can cost 100 times more to fix than if they\u2019d been spec\u2019d properly or caught and fixed early. Anybody who’s launched a database knows why: real data is at stake, so you have to take twice as much care finding and fixing errors after a database goes live.<\/p>\n

  One major problem is that old-style development processes\u2014the ones that were more common back in 2005 when this report was written\u2014aren’t optimal for preventing errors. Instead they count on a limited round of testing just before launch to find and fix errors. This is hard enough to do when the errors are programming bugs. But if the errors are due to poor planning, bad specs, or poor communication then it’s easy to see why such software can’t be repaired well enough to launch it. One major solution is to use a method of development that can prevent errors from getting into your software in the first place.<\/p>\n

  The IEEE report says that IT projects fail when the costs to repair badly-done works exceeds the cost of creating spec’d features. Some of the causes they cite are:<\/p>\n

  \n
  • Unrealistic or unarticulated goals<\/li>\n
  • Badly defined requirements<\/li>\n
  • Inaccurate estimates<\/li>\n
  • Poor communication<\/li>\n
  • Poor management<\/li>\n
  • Use of immature, or inappropriate technology<\/li>\n
  • Stakeholder politics<\/li>\n<\/ul>\n

    Fight Failure with User Centered Design<\/h2>\n

    Next time you get pushback from a client about the extra costs of the planning and design phases of a project, refer to some of these facts about why software fails. It’s easy to see where taking preventative measure gets a big ROI if the project takes user needs into account from the get-go. True, User Centered Design (UCD) doesn’t fix all the problems cited by the IEEE. UCD can’t fix budget, scheduling or bad technology choices.<\/p>\n

    <\/p>\n

    But even an outside consultant can overcome bad management and poor communication when UCD techniques is applied to a project. UCD is all about developing regular contact with users. So if you’re working on a project where goals are poorly articulated, access to users will help you figure out what the goals are. It’s the same with gathering requirements: when meet with users, they\u2019ll tell you what the requirements mean. And since User Centered Design is all about regular communication, you\u2019ll eliminate the problem of inadequate communication between all the players.<\/p>\n

    Poor project management can be the result of not knowing how software development works. With a UCD approach, you can effectively become the project manager, or at least steer the manager in the right direction. When you have direct access to users, you can give more weight to the Pam Halberts on the team over the Dwight Schrute types who\u2019d rather see a project fail than see other team members succeed.<\/p>\n

    Download<\/a> the full report.<\/p>\n","protected":false},"excerpt":{"rendered":"

    The Institute of Electrical and Electronics Engineers (IEEE) did a study in 2005 that examined large software project failures (in the multimillion and billion dollar range)\u00a0 to try and figure out what they had in common. Here are a few facts sobering distilled from that report: $1 TRILLION spent worldwide on hardware, software and services […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\t\n