SPI Figure When Planned Value is 0

Member for

19 years 1 month

You don't need movements when tabulating line items (rows) that may occur on a particular period (column) which I think made floats or criticalities irrelevant in EVM. Once you run your schedule, line items (or tasks) shall be placed on corresponding period(s) depending on logics and actual performance, while of course your "planned values" remain static (as in baseline schedule). And you cannot calculate floats vertically anyway, so why bother?

Member for

21 years 8 months

To write any number including 0 when SPI is undefined would be wrong, better keep the SPI field empty and use some formula to identify when SPI is undefined. This will warn others such unusual occurrence happened.

  • In the following scenario SPI for Activity 2 is undefined while for Activity 3 is 0.
  • Baseline bars are shown in light blue.  Activity 2 is ahead of schedule.  If the SPI is less than one, it indicates that the project/phase/activity is potentially behind schedule to-date whereas an SPI greater than one, indicates the project/phase/activity is running ahead of schedule. An SPI of one indicates the project is exactly on schedule. Therefore it cannot be less than 1, in no way can be 0.
  • When dealing with SPI values "empty" does not always means 0, can mean [in rare ocassions] the value is undefined.

EVM190404-C

Member for

21 years 8 months

EVM does not distinguish available float, it does not distinguish between critical and non-critical activities. Tracking variance at the activity level without taking into account float makes no sense. We must pay attention to critical activities and resources where EVM is of little or no help.

  • An S-curve is a result of schedule logic. On the level of activities, projects tend to have many paths, some of them critical, other not. A tiny (if compared to total project duration) schedule variance of an activity can become a cause for substantial rearrangements in the project network, it can change critical path or order of activities, enforce a total reorganization of works. This cannot be captured by either Earned Value or Earned Schedule calculations - potential problems might be masked by compensating positive and negative schedule deviations.
  • Earned Value Analysis does not distinguish between the works done on critical activities and activities with sufficient floats. A project could be late but EVA will not notice this problem if Earned Value exceeds Planned Value.
  • Earned Value Analysis motivates project managers to do expensive tasks first delaying cheaper activities that could have higher priorities.
  • The Department of Defense [DOD], the father of the creature is against the use of EVM in fixed price contracts.

The schedule contract milestones give us all we need to know if ahead/behind schedule; Cost Accounts tell us if we are under/over budget.  It is simple; no esoteric procedures such as EVM are required, no EVM jargon only a few at the field understand.

  • If you must live with EVM learn its limitations.
    • Earned Value Management as a tool for Project Control
    • - "However, if to be implemented, the method should be used according to its purpose: it is not a tool for forecasting; instead, it facilitates progress monitoring, determination of project status (on time? to budget?), identification of potentially negative occurrences and a rough estimate of their combined effect on the project’s outcome. If the project is to be managed consciously, these occurrences should be then investigated into by means of more accurate methods".

Member for

19 years 1 month

When BCWS = 0, then it simply means that there were no scheduled works during that particular period (perhaps it is a non-working month?). On the start of the project, of course BCWS = 0. Well I guess your managers are just pragmatic, and of course will not believe that BCWS = 0 when the works are in progress, while literally spending or losing money in the project. Do not be blinded by software calculations. When something "undefined" occurs, then it simply means that there's something wrong with your plan.

Member for

21 years 8 months

  • EV is also known as Budgeted Cost of Work Performed (BCWP)
  • PV is also known as Budgeted Cost of Work Scheduled (BCWS)
  • AC is also known as Actual Cost of Work Performed (ACWP)
  • SPI= EV / PV   = BCWP/BCWS
  • CPI = EV / AC = BCWP/ACWP
  • If BCWS=0 then SPI is undefined not 0 as division by 0 is undefined.

Please take a look at the following image.

SPI190404A

  • In the top version Phase 2 SPI = 20/0 = undefined, nothing is shown.
  • In the bottom version Phase 2 SPI = 20/0.20 = 100.
  • As the denominator [divisor] goes closer to 0 SPI gets closer to ∞.  In ordinary arithmetic, the expression has no meaning, as there is no number which, when multiplied by 0, gives a (assuming a ≠ 0), and so division by zero is undefined. 
  • http://mathworld.wolfram.com/DivisionbyZero.html

Member for

20 years 7 months

Thanks folks, yes it is only the in period progress that I have the issue, cummulative progress is correct SPI.  I am just in the unfortunate phase where design is finishing later than planned, and there is a gap in my progress where design eng is completed and install eng has not yet started.

Thanks Zoltan, but as my in period planned value is zero, so the SPI returns a zero figure.

In my mind zero is the correct answer, however I have reporting managers who do not understand it is zero, and are suggesting I change it manually, which i'd rather not do.

Member for

24 years 5 months

So that is a periodic progress since you said "this month"?

I think the only way to represent that is to report the earned cumulative progress vs the planned cumulative progress which is the usual way I do and not the periodic.

Member for

16 years 3 months

are you using physcial % complete ?

divide the earned value by the planned value