10 Project Metrics to Track
10 Project Metrics to Track
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Improving your business processes should not be a stop-start, big bang implementation of new ways of working, it should be a continuous process of analyzing the work you have done and identifying ways in which you might do things better in the future. If you identify potential improvements then you should set yourself up to implement them and then measure whether the expected benefits materialize. Here are my top 10 Project Metrics that you can easily obtain to feed into that Business Process Improvement cycle.
1. Employee Utilization
Utilization is the #1 project metric for a good reason, the numbers that drop out of the timesheets should tell you whether your projects are over or under resourced and in which areas. Unfortunately utilization almost always has two points of failure: self-reported time is a notoriously unreliable statistic and people classify time incorrectly.
There is a simple technical solution to both problems. Increase the accuracy of self-reported time by implementing approval workflow where the approver must verify the accuracy of the timesheet without being able to alter it in any way. If you allow the approver to alter it you run the very real risk of exacerbating the problem of inaccurate ‘self’ reported time as many approvers have good reason to want to alter timesheets that have nothing to do with increased accuracy.
The solution to Invalid classification of time is to provide the person reporting time with classifications of time that match their real world experience. I have seen timesheet systems that do not allow the recording of non-billable time on client projects. This is nonsense if it is possible that not all of the time on a client project can be billed. Make sure that you use a system with sufficient Time Types and recognise that those types may or may not be billable.
2. Project Realization
No matter how accurately you track utilization the system is still prone to failure unless you also track realization. It is not uncommon to find that shortly after the introduction of time monitoring to address low billings most peoples’ utilization stabilizes at the company standard. This project metric tells you if people have learnt to play the utilization game. Show actual billings against utilization so you can ask the question “how come everybody is 70% utilized but the revenue is so low?”
3. Resource Allocation by project
Tracking roles accurately against your employees (in defiance of Agile if you need to) is the key to this project metric because it is about identifying skills that you have a shortage or surplus of. Perform predictive analysis of the roles that will be required on your projects and compare that to a bench if you have one. Most organizations have enough resources because they grow to meet their business base, they just don’t have the right resource mix.
4. Potential vs Actual Billings
This metric is exactly what it says it is. Find the difference between what the salesman sold and what the client agreed to pay! Hold a rate card against every employee, even if you track billings on a job rate, then run an analysis of what the client would have paid if they paid according to the rate card and what they actually paid. Find out where you are giving money away and stop doing it if you are.
5. Project Resource Spread
Low utilization can mean a likely exit from the company so when a new opportunity to record billable time comes along the temptation is high to take it. This project metric is an analysis of billable time and when it occurred and can be done for any project that has been running for a while. Projects often get front-loaded with time and it is not uncommon for projects to have many hours of billable time without a single billable task having been performed. This will come back to haunt you! Front-loaded projects are also symptomatic of not having enough Time Types.
6. Project billing spread
Do the same analysis of project billing as you do for resources. You are looking for bills that go out ahead of delivery. It is fine for a businesses that needs cash flow to bill as early as it can but you don’t want your projects (or people) punished later on because the company got the money before the work was done. Remember that company accounts operate in Financial Years and the money that the project delivered in FYx is soon forgotten when FYz comes around because it is not so visible.
7. Missed milestones (need project baseline)
Very few people record a project baseline, which is a pity as one of the more useful project metrics is the number of missed milestones and the amount that they are missed by.
8. Late features percentage
How good is your business analysis and ability to extract requirements from a client? Calculate the time spent on features added after the development phase kicks off and calculate that value as a percentage of the overall time spent on the project. It should be very low indeed!
9. Error Task percentage by time
Just as you need different types of time to record work so you need different types of error tasks. An error task is what you do when an error is reported and in this respect the subsequent diagnosis will show that an enhancement is not a bug, which is not a user error, which is not a layered software incompatibility etc. Recording the percentage of time spent on different error tasks drives many soft benefits like identifying training needs, helping to plug gaps in software and operations etc. A lot of good input into ITIL processes can be derived this way.
10. Customer interface hours
Keep a log of time that the team spends in direct contact with the client. The Agile methodology says you should be in daily contact with ‘business people’ but in reality this can be difficult, there are many teams that don’t use Agile, and contact will vary from person to person. It can be very useful to compare this metric with others, say the Late Features percentage and Missed Milestones. This is also a metric you can show the client as justification for certain issues (they will be amazed that you track it) and costs.
Opinions expressed by DZone contributors are their own.