Defining Success for Applications That Aren't Sold

Jim has a good post stressing that developers need to know how well the products they made are selling, so that their goals and interests are aligned with the company's ultimate goal of making money.  This is a good point that, in my experience, often goes overlooked or is underemphasized by a software team.  Things like quality and release dates are closely monitored and used as indicators of success, but whether the product is actually profitable isn't tracked as rigorously by the team.  (It is, of course, monitored closely by other areas of the company).

However, a question popped in my head when reading the article: what about when you're working on an application that merely serves a support role within the company? The application itself isn't sold; it's just an in-house tool used to improve existing business processes.  So how do you define success for these applications?

Since you can't really directly translate these types of applications into actual dollars, you need to find other metrics to use for objectively determining the application's value to the company.  Devising these metrics, however, is where I start to struggle.  You need something that shows that a task or process was really difficult or time-consuming, and the application made it easier or faster.  Or something was really expensive to do, and the application somehow made it less costly.  But it's not enough just to say the application is easier, safer, faster, or cheaper; you need to be able to state that it's x percent easier or y dollars cheaper in order to gather some objective insight into the application's success.

Yet people aren't always translating these time-consuming, laborious, and/or risky tasks into metrics, let alone actual dollars.  They just know that they have a situation that could be better solved by software.  Then software is implemented to address these problems, but you're not sure how successful the software was at solving the problems because there was nothing concrete to measure it against.  When talking to Jim about this, he mentioned that with in-house applications, you're often closer to the clients, thus allowing you to gather information like customer satisfaction scores that can be used to gauge success.  I think this information is useful, but as Phil Haack recently opined, customer satisfaction can be tricky to measure.  Plus I still want to see how the application objectively, concretely contributes value to the company - and particularly to the bottom line.

As of now, I can think of a few things to help measure the success of applications that aren't sold: hours saved, money saved, increased accuracy, decreased risk, and improved access to information.  But I'm not sure how to measure these things or how well they translate to the bottom line, so let me know your opinions on measuring the success of these types of applications.