I'm part of a 7 person software development team which supports a company with a few thousand staff. Our team is putting together a quick review process for measuring the success of a software project. Projects are mostly internal, which means our "customers" are more often than not other staff. Projects are reasonably small (generally 100 to 1000 hours).

Our review process will need to have a few aspects to it, probably including:

  • A questionnaire sent to the customers (filled in by people in a variety of roles if possible, such as managers who may not be users of the software, and users), looking at the ease of use, quality of documentation, incident response, value for money, reliability.
  • Cost compared with the budget. Estimated development time compared with actual time would be looked at here too.
  • Security, if applicable.
  • Maintainability, such as how easy it is to log in as a particular user to replicate problems, and how easy the code is to follow.
  • Technical documentation, such as instructions on setting up development environments and test data.

Is there anything glaring I've missed, or anything that should have a particularly strong (or weak) focus?

  • 3
    What were the goals of each project when it started? Did it meet those goals? Commented Mar 6, 2014 at 1:37
  • to expand on bob's comment - what was the expected vs actual return on investment of the project? Commented Mar 6, 2014 at 2:37
  • Make sure to include the cost of bugfixes/quality.
    – Telastyn
    Commented Mar 6, 2014 at 2:50

2 Answers 2


Congratulations on accepting the simple task of solving one of the most controversial aspects of software development - measuring software developer value.

My advise is to start with a very clear understanding of what the intention of how this analysis is going to be used, as that 'flavours' what kinds of metrics are appropriate, and how effective you are going to be at collecting that that information.

Possible goals include:

  1. Understanding why some projects are perceived as more successful than others, and identifying what things can be changed to increase chances of success in the future.

  2. Performance reviews of individual software development team members

  3. Calculating corporate return on investment figures for projects to asses viability of the current approach.

  4. Understanding value added by the software team to the business as a whole.

There may well be more in this list.

When you have a clear understanding of the goal, you are much more likely to get good advice on the types of data you are needing. The types of questions you currently list seem to imply you are heading more towards 3 and 4

  • +1 "How much time is the project saving its user in the performance of their tasks?" would be a nice question for understanding the business value of the project. Might require some up front measurements. Preferably quantitave, but guestimates could be useful just as well. Commented Mar 6, 2014 at 15:11

Beside anything you mention I'll add an agile methodology, like Scrum.

I would like to see something related to Scrum. I believe you can implement Scrum for greater the visibility of how your team is running or working on your projects. Scrum is great for handling imprecise or changing requirements. It will help you because it capture outstanding tasks on a visible backlog and, once a sprint starts, its tasks are immutable.

  • 1
    IMHO, if you have a working "Scrum" process (or any other "agile-buzzword"-process) tells you nothing about the quality of your software products.
    – Doc Brown
    Commented Mar 6, 2014 at 9:27
  • And I agree with you but since the question was about "how to measure the success" and not the quality it seemed to me that beyond all the buzz that the term may have the ideas behind the methodology are good ideas have enhance the visibility of where the project is heading, either to failure or to succeed.
    – James
    Commented Mar 6, 2014 at 14:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.