KPI's of an IT Development Project

Measuring KPI's or Key Performance Indicators is a way to check health of a project. As the name suggests, these indicate the performance of a project.

It is essential to define the KPI's at the start of the project, in fact at the proposal stage. These can vary depending on the type of project (support, development, testing). In this article, I will be focusing on Development project KPI's. These are just a set of guidelines and you can change, add and modify these based on the requirement of your specific project.

KPI's can typically be divided into 5 broad groups: Schedule, Productivity, Quality, Governance and Customer Experience

Schedule KPI's

---

Number of Releases Agreed vs Actual

Defines the number of development releases a team shall do in a specified time period. 
e.g. 1 release per Quarter

Schedule Variance

One of the most common ways to measure the schedule it to calculate how early or late release was delivered as compared to the baseline date. 

Productivity KPI's

---

Number of Stories Committed vs Delivered

In case of a Agile project, it defines the number of stories that were committed at the start of a Sprint vs actual number of stories that were delivered. Another variation of this which makes slightly more sense is 

Number of Story Points Committed vs Delivered

e.g. 20 story points per Sprint. Similar KPI can be defined and measured at a Release level (Release comprises of many Sprints)

Quality KPI's

---

Defect Density

Number of weighted defects per story point

Defects can be weighted as per the Priority of the defect. e.g. High priority defect given a weight-age of 10, Medium priority 5 and Low Priority 1. In case of 1 High Priority and 3 Low priority defects, total weighted defects can be counted as 1 x 10 + 3 x 1 = 13 weighted defects.

This KPI can be measured in Development as well as UAT phase of the project.

DDE (Defect Detection Efficiency)

This KPI's measures the the effectiveness of the testing team to detect defects before it goes to next phase of project life cycle, typically from  Development phase to UAT phase and a good way to judge the teams QA effectiveness. It is defined as 

Total Number of system test defects / (Total Number of system test defects + Total Number of UAT defects) * 100

If required this KPI can be compared as per the priority of the defects to give a fair comparison of pre and post UAT defects.

Reopened Defects

A good way to measure the quality of fixes in a phase is the measure how many of the defects are being reopened. This is measured as 

Number of Defects reopened / Total number of UAT defects

This KPI can be measured in Development as well as UAT phase of the project.

Test  Coverage

Test coverage is a good indication of how good testing team is thinking of various testing scenarios. Better test coverage shall result in more DDE.

Number of functional test cases per Story Point

Code Coverage

Writing unit test cases for the code is a good way to prevent the kind of defects which are difficult to capture as part of functional testing.

Number of Unit Test Cases per 1000 Lines of Code

Story Acceptance

Story acceptance by Product Owner is a great way to test if development has been done by team as per story specifications

Number of stories Accepted/Number of stories Delivered

Governance KPI's

---

Often ignored, but one of the most important set of KPI's are Governance KPI's. Why ? Lets see..

Weekly meetings planned vs Actual 

Communication with customer both formally as well as informally is the need of the hour as more often than not communication failure is a reason for project failures. 

Number of weekly meetings planned /Number of actual meetings 

This KPI is a great way to measure customer engagement and same can be measured for monthly Governance meeting or Quarterly Business meetings which are more strategic in nature

Customer Experience KPI's

---

Customer Satisfaction Survey (CSS)

Taking formal feedback from the end customer is the ultimate way to gauge the quality of services provided. This shall be taken at least quarterly and can be measured on a scale of 1 to 5.

Number of escalations in a quarter

Number of formal escalations by customer per quarter is measured as a to gauge the Voice of Customer.

The above list is only a sample of KPI's to get you started. You can think of many more that suits your project needs. While it is always a good idea to define and measure KPI's in such a way that it reflects the true health o f the project, but let me warn you with a word of caution. Do not get blind folded only by the numbers KPI dashboards give !!! Though formal customer communication is showcased as one of the KPI's above, but nothing can beat a casual talk with customer, so just pick up the phone can call him/her now:-)

--------------------X--------------------

My team is very productive. Really !!!

In today’s competitive world, majority of the organizations (IT service Industry in particular) are facing a challenge to sustain good gross margins. There are many proven as well as new and innovative ways that have been devised by these organizations, that will help them improve on gross margins. Top most of these being improving the productivity of the existing team.

I am going to talk about only one way which has been implemented in our company and holds the potential to improve productivity.

Typically there are 2 types of people in the project (Makers and Managers). Makers are primarily developers and testers whose main focus is on designing, coding, testing, development, creative work etc. and Managers are (as name suggests) whose main work is planning, preparing for meetings, doing meetings etc.

Makers are the people who need Sustained Attention (i.e. manage high attention spans as they need to be focused for longer duration in order to write good code, do good testing etc.), while Managers need Alternating Attention (as they need to focus on multiple tasks and activities and need to switch between then quite often).

In today’s digital world lot of information is available but at times this can distract people.  Similarly as part of Agile best practices, where a lot of open conversation is encouraged for good reasons can cause and break sustained attention spans of people who want to focus long hours on writing their core logic. Both of the above can have a negative impact on the sustained attention span period of teams, makers in particular.

As per Harvard Business Review report, there are 22 interrupts that we get from others per day and as a manager this number is a daunting 50-60 interrupts per day, which means 1 interrupt per 8 minutes. And it takes us 23 minutes to get back to our 100% concentration.

So in order to improve team's productivity, one of the very essential and key aspects is to minimize interruptions. In order to do this we implemented something called FOCUS HOUR. Here are the guidelines of focus hour:

Focus hour was a time period in which team members were supposed to focus on their core activity of the day without getting distracted and without distracting others. We implemented this 2 times a day (1.5 hours each). Teams members were supposed to equipped themselves from all information before this period starts. They shall seek all guidance, help etc. before this hour. Other key guidelines for the Focus hours were:

1. Switch off email notifications
2. No Phone calls
3. Avoid breaks
4. No outsider to be allowed to come in the working areas
5. No conversations

We received a positive feedback about Focus Hours from all the teams though it is yet to be seen how exactly we can measure productivity improvement post this strategy has been implemented.

--------------X--------------