Styles

Monday, October 24, 2011

Measuring the success of software projects

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.  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 asked to rescue 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

Have any of you tried to measure project success more along these lines?  Did it work?  Why or why not?

No comments:

Post a Comment