I think everyone will agree that it’s probably not worth the time to optimize a report that runs once a month at 3 AM on a Saturday to go from 10 minutes to 2 minutes.  Most people would also agree that it’s worth optimizing a query that users have to wait on nonstop all day long to take it from 5 seconds to 2 seconds (or even 4.5 seconds depending on the amount of time it’d take to accomplish that change, 10% is still pretty huge for something being used constantly).  For the latter, you can probably take the improvement percentage and multiply it by the salaries of all those affected and come up with a number… but is it fair to assume that that number goes straight to you?

Let’s take a data entry process for an example.  We’ll say we have employees doing data entry and 50% of their time is spent entering things that rely on a stored procedure that takes 5 seconds to run.  You improve that SP to run in 1s.  While this is obviously an improvement, is it fair to take 80% of 50% of their pay and attribute it to your performance savings?  I’d say not.  For one thing, you have the keying in of the information before they hit save and wait on the query.  Let’s say they spend half their time typing and half of it waiting on that query to run.  We’re now talking about 80% of 25%.  Then, factor in the rest of the process.  Perhaps that 5 seconds that they spend ‘waiting’ is really spent flipping to the next page of their data or tabbing to some other application which it takes them 3 seconds to do anyways.  Now you’re only talking about 40% of 25%. 

At the very least, you can *guess* at what number you saved there.  The numbers are a lot harder to get for anything that users don’t directly wait on.  A few examples of these types of queries might be:

Agent Jobs that run constantly throughout the day
Pre-aggregated reports or data tables that run periodically and store that data for on demand usage
Processes that take only milliseconds but might perform more reads or writes than necessary but are run hundreds of thousands of times a day.

Is there any direct ROI on improving these things?  Maybe… maybe not.  If that process that takes a few milliseconds but runs constantly takes more locks than it truly needs, it could lead to slowing everything else down by fractional amounts or cause blocking/deadlocking issues in your database that ‘freeze’ users and force them to wait, thus wasting time and money.  However, maybe it never would have gotten to that point.  If you weren’t proactive with fixing that because it wasn’t causing any problems right now, it could end up costing the company tens or hundreds of thousands of dollars in lost productivity if and when it DID become a problem.  You could measure that.  But is it fair to measure it if you addressed the issue preemptively and it never happened?  How do you come up with a number in this case?  How do you decide what to count *for* yourself and what to count against yourself? 

Going a completely different route, let’s look at bug fixing.  Let’s say you identify a loophole in the invoicing process that only applies to .05% of invoices because of the rare criteria.  Maybe that loophole only cost you a few hundred dollars for the 2 years it has existed, but it *could* have cost you thousands depending on which line items it happened to affect.  Do you count the hundreds of dollars it already cost you, or the thousands of dollars it would have eventually cost?

Then you have the customers to take into account on things like a public facing website.  This is also nearly impossible to measure.  If your web queries are all inefficient and slow, it might make your website feel sluggish, unresponsive or broken.  Your queries could also have bugs that return errors to the customers.  Addressing either of these things is obviously going to improve your customers’ experience while browsing your website, but how do you convert that into a physical dollar amount?  Can you claim a percentage of the revenue from that customer because you improved their web viewing experience?  I doubt the sales team would agree with whatever percentage you thought should be attributed to IT/development.  What about additional features on the website that are the deciding factor in getting new customers?  In most cases customers aren’t going to come right out and say "You know, I was really on the fence about which company to go with, but seeing that I could just check my ___ on your website really made me choose you." 

At the end of the day, if you really want to calculate a dollar value of the things you’ve done, I think you have to break things down to a very low level.  Create a range for each thing you fix, improve or create and have that range readily available.  Then when someone asks, you can present your numbers with a range for each item and they can make up their own mind at what is fair. 

Unfortunately, most companies view IT/Development as a ‘necessary evil’ that doesn’t produce anything.  These numbers probably aren’t going to change their minds, but you should at least be able to keep the focus on ‘necessary’ and off of ‘evil’.  The irony is that just about everything work related you do potentially saves or makes the company money in some manner… everything except sitting around trying to calculate how much money you’ve saved them.

They aren’t completely dissimilar; they behave exactly as you would expect them to… with the exception of NULL’s.  Because nothing EQUALS NULL (Dependent upon settings, see below) the difference in the internal logic matters.  Gail Shaw initially explained this to me when I asked the question on the forums and I wanted to use her explanation here, but I can’t seem to find it; so here’s my own version of an explanation:

When you use IN, you’re really saying "WHERE myvalue = ‘A’ OR myvalue = ‘B’ OR myvalue = NULL"
Your NULLS won’t cause the entire statement to fail because it’s only an OR.

When you use NOT IN you’re really saying ‘WHERE myvalue <> ‘A’ AND myvalue <> ‘B’ AND myvalue <> NULL “
This is where the problem arises.  Since a NULL in SQL is an unknown value, you can’t test = or <> on it and you get no results.  Without the NULL, you’d be fine.

Here’s a simple example to demonstrate.

DECLARE @T TABLE(
Val varchar(5)) 

DECLARE @T2 TABLE(
Val varchar(5)) 

INSERT INTO @T(Val)
SELECT 'A' UNION ALL SELECT 'B' UNION ALL SELECT 'C' UNION ALL
SELECT 'D' UNION ALL SELECT 'E' UNION ALL SELECT 'F' 

INSERT INTO @T2(Val)
SELECT 'A' UNION ALL SELECT 'B' UNION ALL SELECT 'C' UNION ALL
SELECT NULL 

SET ANSI_NULLS ON
SELECT * FROM @T WHERE Val IN (SELECT * FROM @T2)
SELECT * FROM @T WHERE Val NOT IN (SELECT * FROM @T2)
SELECT * FROM @T WHERE Val NOT IN (SELECT * FROM @T2 WHERE Val IS NOT NULL) 

This issue is further complicated by the ANSI_NULLS setting.  While I believe most people have this turned ON, the fact that it is an option introduces another variable into the mix.  NOT IN will not fail in the same way if you have ANSI_NULLS set to OFF.  (Try the above example again after changing ON to OFF)