Development KPIs - performance or deliverables?

One of my duties as a Development Manager and Director is defining the individual and team KPIs. As well as validating productivity, efficiency of development and quality of the final product and solution. The key here is the "deliverable product". In a creative technological world, we are not "performing", and none of the old-school indicators like lines of code, working hours and project cost actually reflect the desired output.

At the same time there is a necessity to measure and compare the workload, efficiency and quality of software development.

The most generic evaluation I use is based on clearly-defined workflow. Some role-based examples are presented below.

Product Managers

How many versions of the initial Documentation (MRD, PRD, SRD) are needed due to uncertainty or missed requirements? Usually corrections are requested by developers and sometimes by business analysts. We do not talk about misspelling or minor corrections. Only major document versions, signed by Product Manager as ready for development. The tool for the measurement: version control application, the ideal document: single version per release.

The content and the structure of the documents is also very important. Besides the Business Requirements the scope should include: 

• System Performance Measurements - desired or acceptable execution time for the most critical transactions;
• Compatibility and System Limitations - supported environments and devices, related performance and capacity levels, warning and critical thresholds ;
• Stability and continuity - what should occur if the above criteria is not a match, how the system behaves when exceeding the limits, what dependencies are affected and what interaction is needed with other modules and a user interface;
• Usability - user-friendly interface, required time/clicks/inputs to complete an operation, what kind of input validation/security checks are needed, are there any intelligent / adaptive / self-learning components.

If any of these topics are missed or not yet covered with proper details, the document has to be revised, which should be indicated as a new version.

Development Managers

How many times have initial estimations of workload and delivery dates were corrected or missed? A manager should be able to define milestones for the team with reasonable accuracy; especially for short-term goals. They should know the individual strength of each developer, assign and prioritize tasks to utilize the team's power and provide the highest quality product. The measurement tool: task management application; and the ideal planning: no corrections, no postponed or undelivered tasks.

Developers

Any developer is responsible for delivering the solution by a) matching all the requirements, b) ensure it is according to the schedule, and c) with the highest quality. Indicators are the completion on the due date and how many bugs are found by Quality Assurance (QA). We also use a severity scale for the bug; for example counting it with "t-shirt sizing" - small, large, extra-large etc.

Size of the code or number of corrections are not critical and are not even considered as soon as the output matches the requirements and the timeline. In my practice I have used work-hour reports only for future planning, workload balancing and non-development activities such as vacations, training, business trips and experimental "hackathons".

Solutions, provided in a rush or under stress with enforced deadlines, usually have very poor quality. At the same time "relaxed mode" means not enough motivation or commitment. This is solved by healthy inter-team competitions. The measurement tools: task management/planning and ticketing/bug tracking applications, and the ideal solution should be completed with planned resources, match all the requirements and delivered in time without any bugs (except if confirmed by Product Manager as "known bugs").

Quality Control or System Verification Team 

The team's obligation is to develop proper test cases which cover all aspects of the product, as described in requirements for new features. As well as regression testing, crash-testing, etc. The number of bugs found is a positive indicator for QA, and a negative for responsible developers. At the same time, any execution issues or bugs that are reported by end-users, customers, or a maintenance team affects the factors of success. The tools: support ticketing and bug tracking applications; the ideal product: a bug-free, stable, self-reporting and self-adjusting solution.

I suggest to replace Key Performance Indicators for development teams with Key Deliverable Indicators (KDI) as described above.

On top of this, using the KDI-based virtual points system, will allow the developers to accumulate and redeem any collected points for things such as movie tickets or extra vacation days. This would bring a new level of job enjoyment and satisfaction. As result there will be better products and everyday tools.