3

I worked on a project that brought the execution time of a query to 18 seconds from 5 minutes earlier. About 100 employees use this query to generate reports and further do their jobs. I am trying to find a way to project to my manager about the value gained by my efforts. This is what I have in my mind:

$saved=(4min42seconds) X (100 users) X (at least executed once a day) X (21days or 1 month) X (employees cost to company an hour)

Should I just report how much more efficient the new query is, since I don't know how to translate the 4min42 seconds in terms of % more efficient, or should I use this formula to translate the efficiency gain?

15
  • 4
    Before you present anything to your boss, double-check your math. 5 minutes - 18 seconds is not 3:42. That said, keep it clean & simple - made the query 16X faster & reduced database resource utilization, allowing more people to use the system & execute their reports faster, with the same amount of hardware resources. If there's billing done per-CPU hour or other measures, mention that cost savings as well.
    – alroc
    May 6, 2013 at 18:44
  • 1
    I'm voting to leave this open, BUT with some conditions. The scenario you gave is excellent as an example, BUT if we focus only on it, I believe the question becomes too localized. If this question could be extended/edited to use the query situation as an example for a situation where one has made extreme improvements to an existing process, and would like to bring it up with their boss in a proper manner, I think this question would end up being extremely strong.
    – acolyte
    May 6, 2013 at 19:57
  • 2
    Six Sigma has quite a few methods of calculating the cost savings of a project. It is not just the time you are saving people waiting for the results but how many more people will use the query now that they do not have to wait 5 minutes for it to run. May 6, 2013 at 20:42
  • 2
    @acolyte: good idea to double check, but I've seen performance gains several magnitudes greater. It all depends on the skills of the developers in each end of the problem. May 6, 2013 at 21:21
  • 1
    @acolyte, I have brought things down from hours to seconds in db performance tuning. 5 minutes to 18 seconds is entirely believable.
    – HLGEM
    May 6, 2013 at 22:07

2 Answers 2

7

OK, In the spirit of the comment thread, I'm going to stay out of the details here:

Reporting on Cool Things You've Done to Management:

  1. Know when a metric will help you - doing a quick verbal status report probably doesn't need a heavy metric. Just saying "I brought our slow query from 5 minutes to 15 seconds" is pretty cool, and a good technical manager will get that. Especially if this was a few days of effort, don't go crazy.
  2. Report big stuff in a big way (understand impact/work scope) - if this was a many week effort, or something with a high degree of complexity, take more time to figure out how to be clear about your impact. Putting a spin on success takes time, so only do this with the time you'll take highlighting the work is less than the work itself.
  3. Know what numbers the bosses like (understand audience scope) - for example

    • A technical manager who's fixed queries himself is likely to be happy with hearing the query that was 5 minutes is now 15 seconds - everyone was complaining about that query, and he knows that this is a great thing.

    • A project manager cares about team efficiency - a number more like "I saved the team X hours of time waiting for the query a month" is likely to help. Also - for a reasonably technical project manager or big picture person, being able to highlight extensions of this success are helpful - for example, in a software project - speeding up a build process moves the capabilities of your team from nightly builds to build before check-in - which means a whole new and more efficient method of developing code. That's not just the time for a query, it's the time saved from all sorts of check-in errors and bug fixing.

    • For contract work, the bosses and customers may care about $ saved. If development costs were X dollars/hour, and now you've saved N hours, you've saved X * N dollars. Not something to make up on your own - check in with your direct management to see what cost estimates you can get.

  4. Show any basis for estimate - to do a calculation, you'll end up making some assumptions - the length of the query you know - but how are you figuring out how often people use it? Is that really everyone, or just the a sub-group of users? Justify your estimates and clarify where you've had to make some.

  5. Check before sharing - always check in with management before quoting metrics to external parties. The farther you are sharing, the more you should check in. Telling another team in the same company is far less of an issue than telling customers or competitors, for example.

2
  • A very good answer covering everything I needed. My manager just moved in the position from the Chemical Dept.! I just joined in as program manager with dbs bg. He might not care too much about execution time, as for him, others were anyways performing according to their job expectations. So, taking your advice, I think it be good to convey the metric in time terms, both for query execution and my efforts! be casual and yet informative. P.S:Read your profile! would marry you if I could. ;)
    – camelbrush
    May 7, 2013 at 0:56
  • Glad it helps. :) May 8, 2013 at 20:25
4

It depends on how you report your efforts. Will you be doing a presentation, formal report, email etc...

If you are reporting it at a high level such as email or powerpoint to higher ups then just display the range of possible savings in whatever unit you desire-- savings per day, week, year...

If you are reporting it as detailed report with technical information then include more about how you derived this savings continuum.

How to guessimate your savings range...

I simplified your formula...

WageSavingsPerDay = AvergaeWageRatePerAction * Executions

Now guess low estimates for hourly wages and how many times you think the query will be executed.

Example Low End: $15/hr, 100 times a day (executions)

AverageWageRatePerAction = $15 * .0583(% of an hour the new query time saves) = .875

therefore the low end would be...

WageSavingsPerDay = .875 * 100 = $87.50

Now repeat for the high end...

Example High End: $25/hr, 165 times a day (executions)

AverageWageRatePerAction = $25 * .0583(% of an hour the new query time saves) = 1.46

Therefore the high end would be...

WageSavingsPerDay = 1.46 * 165 = $240.60

By reducing the query time of x task I have saved the company between $87.50-$240 in wages per day depending on query frequency and wagerates.

Obviously the better information you have regarding wages and query frequency will improve the accuracy of your calculation. This also assumes that people are not productive during the previous duration of the query.

Additionally it should be noted that wages saved may not be the only manner in which a firm would save money.

For example: Reduced query time also reduces CPU usage which also could lower power consumption...etc

1
  • +1 for the well stated answer and the low-high range considerations. That would be a good way and also more casual way to communicate the efforts. Thanks
    – camelbrush
    May 7, 2013 at 0:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .