Metrics and Key Performance Indicators
What is a metric?
A project management metric is a quantifiable measure used to gauge project performance or progress.
You derive metrics by comparing to a predetermined baseline of two or more measurements taken over time.
What is a Key Performance Indicator?
A Key Performance Indicator (KPI) is a quantitative measure used to evaluate project performance against expected results; they confirm that the project has achieved its objectives.
KPI’s are measures that can used to demonstrate how effectively an organization is achieving its strategic and operational goals.
Why are project metrics and KPI’s important?
Project metrics are important so a project manager can evaluate a project’s status and assess project team productivity and quality of deliverables.
Project KPI’s are important so a project manager can show the performance of the project in delivering what the customer needs and ultimately to determine the success of a project.
How do I create metrics and KPI’s for my project?
Above all else, be sure the thing you are measuring, to determine project progress or success, is meaningful to the project stakeholders. No matter how accurate you are in your measurement, if the result does not resonate with your project stakeholders then the result is merely a meaningless measurement.
What to measure? What is important to the project stakeholders?
- A project that delivers on time?
- Satisfied customers?
- Meeting project quality targets?
- Finishing on or under budget?
- Something else?
A commonly used, best practice for developing well-written, meaningful metrics and KPI’s is to employ the S.M.A.R.T. approach, first presented by George T. Doran in the November 1981 issue of Management Review:
- Specific – target a specific area for improvement.
- For information technology project management this can be any of; Process, are you following a standard, widely accepted project management methodology? Progress, do your measures indicate you are on schedule and within budget? Product or deliverables, did the project deliver what it set out to deliver? Was there scope creep? Quality, is the intended customer satisfied with the results of the project? Are there any complaints or calls for assistance?
- Measurable – quantify or at least suggest an indicator of progress.
- The indicator must be quantifiable. This helps by removing subjectivity. So instead of a measure like, increase customer acceptance of software xyz; measure something like increase customer acceptance of software xyz by 10% over the baseline measurement of March 2017 as determined by customer satisfaction survey.
- Assignable – specify who will do it.
- Use a name rather than a project role. Specifically assign this responsibility to someone. For example, John Doe will prepare and send the customer satisfaction survey to project customers two weeks following the go live date of release to production and report back the results within one week of closing the survey.
- Realistic – state what results can realistically be achieved, given available resources.
- Gauge the measurements and the effort required to obtain those measurements to the type of project, i.e., low, medium, or high risk and complexity. Simple, low risk and complexity projects, probably do not need to use Earned Value Management (EVM) to track project progress, a rough order of magnitude (ROM) estimate may be sufficient. Unless your organization is at a high level of project management maturity, the effort required to obtain the necessary measures for EVM outweigh the benefits from the analysis.
- Time-related – specify when the result(s) can be achieved.
- To avoid issues do not have open-ended requests. Either use specific dates or use deadlines based on project events, e.g., two weeks following the go live date of release to production.
Basic project management metrics and KPI’s for information technology projects include:
- Number of defects, issues, bugs found
- Number of project change requests
- Actual stories completed versus committed stories
- How frequently the scrum team succeeds in reaching the sprint goals (Sprint goal success rate)
- How closely does the amount of work completed agree with the estimated amount of work planned
- Percent complete, i.e., how much work is completed, or how much work remains to be completed
- Velocity, or the volume of work completed in a specified period of time
- Sprint burndown chart, or rate or amount of progress made during a sprint, measured by effort-remaining
- How closely does the cost of work completed agree with the estimated cost of work planned
- Return on Investment (ROI), or a measure of the project benefits versus costs. A positive ROI indicates more benefit than cost
- Budget variance, or the difference between the baseline budgeted costs and the actual cost
- Capital Redeployment is when the cost of future development is higher than the value of that future development, it’s time for the project to end and then the organization may use the remaining budget from the old project to start a new, more valuable project
Examples of information technology project metrics and KPI’s
- Earned Value Management (EVM): Planned Value or Budgeted Cost of Work Scheduled (BCWS), i.e., authorized budget assigned to scheduled work
- EVM: Actual Cost or Actual Cost of Work Performed (ACWP), i.e., the realized cost incurred for the work performed on an activity during a specific time period
- EVM: Earned Value or Budgeted Cost of Work Performed (BCWP), i.e., the measure of work performed expressed in terms of the budget authorized for that work
- Effort Estimation, i.e., an estimation, by an expert, of the amount of work required (e.g., hours) to complete project work
- Percent complete, i.e., a measure based on duration; e.g., if a project task has an estimated duration of 4 days and 2 days have been completed then the percent complete is 50% (2/4=.5)
- Percent work complete, i.e., a measure based on work, similar but different from percent complete; e.g., if a project task has an estimated duration of 40 hours and 30 hours have been completed then the percent work complete is 75% (30/40=.75)
- Velocity, i.e., average amount of work a scrum team completes during a sprint (a fixed time period), measured in either story points or hours
- Sprint Burndown, i.e., tracks completion of work throughout the Sprint
- Cumulative Flow Diagram, i.e., ensure the flow of work across the team is consistent by measuring number of issues over time
- Number of defects found or escaping to production
- Number of customer support requests
- Code churn
- Self-assessment test or survey
- Percentage increase over time of desktops/laptops on which sensitive data scanning tool has been deployed
- Number of incidences of unapproved storage of sensitive data found on desktops/laptops over time
- Spend per transaction
- Earned Value Management (EVM): Cost Variance, i.e., the amount of budget deficit or surplus at a given point in time, expressed as the difference between the earned value and the actual cost
- EVM: Schedule Variance, i.e., a measure of the schedule performance expressed as the difference between the earned value and the planned value
- Business Value Realization - shows the value of the project over time
- Continuous retrospectives
- Customer Satisfaction - usually measured using survey’s
- Business process streamlining - length of time to achieve/complete business process