Think for a minute about driving your car without having any information on the dashboard about fuel and speed. How would you know if and when you can reach your destination?
Maybe you could throw at the beginning an estimate based on average speed and consumption. However, what if you have to pass through the city center during peak hours? Would you still be confident that you can arrive at the destination at the right hour?
The same situation could happen as well in project management: having available the right KPIs about the project status can truly make the difference between success and failure. The KPIs can help the project manager make more accurate predictions about release, perform better change management or request additional resources.
What is not a Good Metric
Before I dive into the details about the metrics I recommend for good project management reports, let me mention what is not a good metric:
- Asking team for a project status. Certain team members might tell you their best guess. But that info is definitely not something you can use in a KPI report simply because it is just a guess. They do not have full overview of the project. It’s not even their responsibility to evaluate project completion.
- Calculate status based on the difference between current date and end date of the project. Such calculations don’t have any foundations on the reality of the project. It is pure fiction and completely avoids the reality of the project.
- Discussing deliverables and setting a delivery dates under customer pressure. Some customers are difficult, others are not. However, being an “Yes man” without consulting at all with the team and with the project realities can lead to major consequences at due date.
How to Collect Data
Before you compile any KPI results, you need to have access to compelling data. I personally collect them with JIRA, however, I am pretty sure any good task management system can deliver them. In regards to the actual collected data, I am using the following columns:
- Task Id. It is used to sum up the original estimates only once per task because the export will list a task several times.
- Original task estimate. It is used for calculating the entire scope of the project. It is mandatory for each task to have the original estimate filled in, otherwise the full scope can’t be defined. However, once the full scope is already calculated, any additional task that is added to the project and doesn’t pass though change management process, it shouldn’t have the original estimate filled in because it will artificially inflate the project scope.
- Username. The username is not specifically needed for the metrics calculations that I am currently displaying in the report but it can make room for additional metrics like who was the most productive team member. Or least productive for that matter.
- Time Spent. This column holds the time spent by each team member. It is used to determine how much work has been done on the project.
- Task Project Status. This column holds the status completion of the project tasks. It is used to determine how much from the project has been completed.
For the moment, two important parameters are specified manually: project start date and end date. I believe in the future they could be extracted from the task management tool.
Key Performance Indicators from Earned Value Management
The key performance indicators that I have listed in the template are metrics well known in the earned value management field.
Based on the data collected above, I am able to compile the following earned value management metrics:
- Budget at Completion (BAC). This is the total number of hours that is included in the scope of the project.
- Earned Value (EV). This represents how much was completed from the project. For EV, I added two values in the report: percentage and the actual number of hours.
- Actual Cost (AC). This represents how many hours the team spent on the project.
- Planned Value (PV). This represents the planned project completion as of today. For PV, I have as well two values in the report: percentage and estimated number of hours.
- Cost Variance (CV). This represents how much work has been done compared to the planned cost. If it is a negative value, then is bad.
- Schedule Variance (SV). This represents how much work has been completed compared to the planned schedule. If it is a negative value, it is bad as well.
- Cost Performance Indicator (CPI). This represents how much value the project gets for every 1 hour spent by the team. If it is under the value of 1, it is not good. If it is equal to 1 and above, is good news.
- Schedule Performance Indicator (SPI). This represents with how much the project progresses for every 1 hour spent by the team. If it is under the value of 1, it is not good. If it is equal to 1 and above, is good news.
- Estimate at Completion (EAC). This forecasts the total number of hours that the project would take to complete from start to end.
- Estimate to Complete (ETC). This forecasts how many more hours are needed to complete the project.
- Variance at Completion (VAC). This forecasts how much over or under the project would be in terms of cost.
Out of the metrics presented above, I personally like to follow CPI and SPI because I consider them to be the fastest and the most meaningful overview you can get. In addition, I like to do decisions in terms of resources based on the ETC metric. If that number looks really bad, then for sure I need to request additional resources in order to make sure I don’t finish the project one year later than planned.
The Project Management KPI Report Template
You can download the project KPI report template excel file from below the article. Consider it as a beta version for the moment. It hasn’t been battle tested enough. However, I believe it can be very useful on your project reporting activities by empowering you with enough visibility to make the right decisions for your project.
Feel free to share any feedback you have on the template.