ASP.NET Security Consultant

I'm an author, speaker, and generally a the-way-we've-always-done-it-sucks security guy who specializes in web technologies and ASP.NET.

I'm a bit of a health nut too, having lost 50 pounds in 2019 and 2020. Check out my blog for weight loss tips!

Measuring the success of software projects

Published on: 2011-10-24

In measuring software project success, many companies use two relatively simple metrics:

  1. Is the project on time?
  2. Is the project on budget?

Both of these are easy to measure, and we measure them in part because both of these are more difficult to achieve than we'd like. However, neither of these two measurements gets at the heart of what makes a typical software project truly successful. There should be one primary thought driving any software project that stakeholders on all sides should use to determine its success:

Does my project deliver more business value than the cost of building it?

Your end goal should primarily be delivering business value, not meeting a budget. Ideally the budget would be somewhat related to its business value, but needs change. I've been involved in projects that didn’t meet time or budget limitations, but were still a business success because they delivered the promised business value, allowing for company scalability, greater market visibility, etc. I've also been on projects that were a success in terms of meeting time and budget, but failed miserably in providing the desired business value. 

So why do many of us still focus on time and budget as primary measurements for software project success? I think largely because they are easy to track and measure. Determining ROI requires knowledge of the current costs and revenues associated with the current process, measuring and calculating all costs associated with development, and measuring the improved costs and/or revenues due to the end product. Separating costs and revenues due to software only and those generated from other causes (marketing efforts, efficient or inefficient workflows, etc.) can be nearly impossible. Pair this with the thought that software projects are ends to themselves and time and budget become more important measurements to project success than they should be.

The alternative requires either a strong project champion that is able to understand all of the costs and revenues from both the business and implementation sides or close collaboration between the business and implementation leaders to determine proper measurements of success. Neither of these is common or easy to accomplish. To get an idea of what I mean, here are a couple examples of better measurements of project success:

  • A new internal document tracking system's success might be measured by increased productivity and worker satisfaction
  • A new content management site for a professional services company might be measured by the number and quality of unsolicited sales leads

This is not to say that projects shouldn't measure time and budget at all, simply that they shouldn't be the primary measurements of success.

This article was originally posted here and may have been edited for clarity.