Comments on: Tie performance to business goals http://www.quicktestingtips.com/tips/2010/01/tie-performance-to-business-goals/ Your daily feed of short software testing tips... Thu, 17 Nov 2011 13:09:27 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: Anthony Panozzo http://www.quicktestingtips.com/tips/2010/01/tie-performance-to-business-goals/comment-page-1/#comment-449 Anthony Panozzo Sun, 03 Jan 2010 19:25:51 +0000 http://www.quicktestingtips.com/tips/?p=1099#comment-449 A similar approach might be to figure out what the actual value of getting a % improvement in different performance metrics. For example, if you can estimate the cost of delay as well as the value for improving performance, you can give the team a project model to determine when it makes sense to spend time improving the performance and when it makes sense to work on other things or stop altogether. You're basically giving the development team more context so they can make an informed decision. My thinking on this was influenced by Reinertsen's Managing the Design Factory, specifically Chapter 2: Project Models Done from the perspective of the development team Quantify what overruns of expense, cost, and performance, and for a one-month change in schedule will do to profitability Better to have simple model that everyone understands and agrees with than to have opaque model — inputs are everything Predict what a one-month change of schedule by analyzing market and potential competition to project delay scenarios Benefits of using project model: make better decisions using data, faster decision making, higher buy-in on team decisions Hope this is along the lines of what you were thinking! A similar approach might be to figure out what the actual value of getting a % improvement in different performance metrics. For example, if you can estimate the cost of delay as well as the value for improving performance, you can give the team a project model to determine when it makes sense to spend time improving the performance and when it makes sense to work on other things or stop altogether. You’re basically giving the development team more context so they can make an informed decision. My thinking on this was influenced by Reinertsen’s Managing the Design Factory, specifically Chapter 2:

Project Models
Done from the perspective of the development team
Quantify what overruns of expense, cost, and performance, and for a one-month change in schedule will do to profitability
Better to have simple model that everyone understands and agrees with than to have opaque model — inputs are everything
Predict what a one-month change of schedule by analyzing market and potential competition to project delay scenarios
Benefits of using project model: make better decisions using data, faster decision making, higher buy-in on team decisions

Hope this is along the lines of what you were thinking!

]]>