Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When I hear Key Performance Indicator I get a little worried because usually the next thing done is to link performance to reward and then you can get unstuck very quickly. I am always reminded of the software firm that decided on a reward system around bug fixing - the testers would be rewarded for finding bugs and the developers rewarded for fixing bugs. Development ground to a halt as an instant black market formed around the insertion, detection and correction of bugs. </p> <p>Your organisational KPIs should be customer focussed. Depending on the type of software product you are making, you can measure it in the following ways:</p> <ul> <li>Sales - Is your product meeting customer requirements? You may be able to measure this in terms of the ratio of software presentations to sales or visits to your web site's purchase page to actual purchases</li> <li>Quality - Is your software understandable and reliable? How many support calls per customer do you get per day? Are the questions about how to do something or errors?</li> <li>Customer satisfaction - How satisfied are your customers with your product? Survey your customers and find out what you could be doing to increase their satisfaction then survey them again later to find out if you've improved. (Don't annoy your customers by asking a lot of questions or doing it too frequently)</li> </ul> <p>Yes, these indicators seem to have nothing to do with the base level software metrics like bugs found and lines of code produced. However, the problem with bugs found is then you have to grade the severity of the bugs, and refactoring will often reduce your lines of code. Timeliness only matters if you are meeting your customer's expectations of timely delivery. </p> <p>Concentrate on the business goals. If you have customers buying your software, they don't need a lot of support to use it and they are happy, then your software organisation is successful. No measure of bugs detected, schedule slips or anything else will matter if you don't have those three things in place. </p> <p>If your software project is like the majority out there, it will be late, over budget, ship with less features than anticipated and have bugs. Don't beat yourself up over these things, deal with them and move on. Yes, you need bug databases, source control, testing and a way of measuring project velocity but in the end if you don't meet the business outcomes then you can't be successful, regardless of how polished and shiny your code is and how few bugs it has.</p> <p><strong>Update</strong> to try to address the revised question</p> <p>KPIs as you desire to use them are difficult when delivering an intangible product that is also often a moving target. Will your KPIs used this year on an accounting system have the same meaning next year when you are implementing a document management system? </p> <p>Let's take as an example a profession where KPIs are used widely - lawyers. Measuring lawyers uses KPIs such as: average billed hours worked per day; hours billed per month; age of debtors ledger; average age of unbilled work; percent of billed fees written off; and so on. You should notice a trend here - all these KPIs relate to willingness (or not) of clients to pay for the services rendered. This is the final arbiter of success and is why I suggested (above) some ways you could use this type of measurement as KPIs for your software business. </p> <p>When you try to get down to having KPIs that don't relate to your client's willingness to pay for the value you are providing, then we get down to problems with what we are measuring, how you are measuring it and what differences there are in the measurement or what is being measured this year as opposed to last year. </p> <p>"Dollars paid by clients" has a fixed value year to year - arbitrary metrics like "bugs in software", "timeliness of release" and "flexibility" don't have a fixed value and an increase in the KPI may not have a direct relationship to the underlying value that is meant to be measured by the KPI, such as "more bugs means lower quality".</p> <p>For example, after the <a href="http://en.wikipedia.org/wiki/Space_Shuttle_Columbia_disaster" rel="nofollow noreferrer">Columbia disaster</a>, I recall the investigation team came up with several hundred recommendations and items to be investigated. Did these newly discovered "bugs" mean the space shuttle suddenly had a lot less quality? Actually, after the investigation the space shuttle had more quality. So a KPI around bugs can easily be distorted by an extensive QA session and more bugs reported may actually mean your software has higher quality. </p> <p>Productivity in terms of timeliness of releases is easily distorted by commercial factors, such as a client throwing money at you to do some custom development for them. Your release schedule will slip but your business will improve. </p> <p>As for flexibility, I can't even hazard a guess at how you would measure something so intangible. </p> <p>About the only measurement I can think of that has value this side of the client's wallet is <a href="http://extremeprogramming.org/rules/velocity.html" rel="nofollow noreferrer">project velocity</a> - how much did we estimate we would do last iteration/cycle/release and how much did we actually get done? Then plug this figure into the time available for the next iteration/cycle/release to estimate how much you will probably be able to get done this time. You can display the time remaining in a <a href="http://www.mountaingoatsoftware.com/release-burndown" rel="nofollow noreferrer">burn down chart</a> or similar during the iteration. </p> <p>The rest comes down to process which I don't think you can pin down to KPIs. All you can do is make sure your developers know what everyone is doing (daily developer meetings), your extended team gets input (weekly or fortnightly team meetings), you understand what worked last time and what didn't (retrospectives) and above all you have transparent effective communication. </p> <p>Unfortunately, I don't think there are any magic KPIs like you are after (but don't overlook the relevance of getting money from clients as a KPI).</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload