The utilization of Earned Value Management for statistical analysis on projects has been around for over 50 years. The calculations are thoroughly covered in PMBOK and are usually found on exam questions for the PMP Certification. While it is important to understand how to calculate these statistics for the PMP exam, it is equally important to understand the rationale for utilization. Essentially, there is a calculated answer and real life implications for practical use and decision making on a project. As a Project Manager, you must understand both.

The following is typical of a question you may see on the PMP Exam:

You have been assigned to a construction project as the lead Project Manager for building high rise condominium units. The initial estimates, based on previous projects of a similar scope and scale, is that it will take 24 months to complete at a cost of $7.5 million dollars. Six months in, you estimate $2.5 million dollars have already been spent and only 20% of the work has been completed. Calculate the Schedule Variance (SV) and Schedule Performance Index (SPI).

The formulas are as follows:

Schedule Variance (SV) = Earned Value (EV) – Planned Value (PV)

Schedule Performance Index (SPI) = Earned Value (EV)/Planned Value (PV)

  • Actual Cost (AC) = $2.5 million
  • Planned Value (PV) = $7.5 million x 25% = $1.875 million
  • Earned Value (EV) = $7.5 million x 20% = $1.5 million
  • Schedule Variance (SV) = $1.5 million – $1.875 million = (- $375,000)
  • Schedule Performance Index (SPI) = $1.5 million / $1.875 million = .80


In the case above, the project is behind schedule from a statistical standpoint. In real life, we must attempt to understand the reasons why this project is behind schedule. The SPI is indicating only 80% of the planned work is being accomplished on a typical day (the baseline is 100%). Before we start thinking about “Fast Tracking” or “Crashing” this project, a good idea may be to understand the root causes for the delay. The SV and SPI are red flags and a cause for concern, but immediately taking action wouldn’t necessarily be wise, not yet. For instance, if you talked with one of your team leads and found out the multiple building permits required have been taking longer than normal to be processed, you begin to realize construction speed isn’t your problem. You note in your project schedule that the requisite permits have already been acquired, yet your team lead insists this is not the case. Ultimately, you find out the required permits have been approved, but this has not been communicated with the team leads due to delays in internal processing of documentation. In this real life example, conducting root cause analysis will go a long way in getting your project back on track. This method for understanding the real problems behind project delays can be extended to any project. The techniques of “Fast Tracking” and “Crashing” a project are very effective techniques for getting a project back on track, but understanding the root causes for delays can go a long way in knowing where to best focus your attention to meet your deadlines.

Like this post? Share it!