During our training sessions in Kansas City this summer I was describing how Primavera users approach status updates differently than many Microsoft Project users. Primavera P6 users will change the Data Date when updating the project schedule to match the cutoff date of progress. So a Data Date of November 1, 2016 means that we have considered all progress up to November 1, 2016. (The default time for the Data Date in Primavera is 12:00 am so normally we do not include any progress on the Data Date; I will explain how to change the default time in another post).
In Microsoft Project there is the Status Date, which functions like our Data Date. But inexplicably, many Microsoft Project users never change the Status Date when updating the schedule. I realize I am using a bit of a broad brush here, but I have personally reviewed many Microsoft Project schedules where I was not able to determine the cutoff date of progress very easily because the Status Date was still set to the day the project started. I end up searching for the latest actual date in the update to approximate what must be the Status Date.
The end result of not moving the Status Date in Microsoft Project is that activities will have planned start and finish dates that are in the past. A nominal November 1, 2016 update will show activities starting and finishing before that date. That would be a mean feat unless one has a time machine! Now, I suspect that many Microsoft Project users are self-taught and the program is easier to learn than Primavera P6 or Primavera Contractor. So it is possible that many Microsoft Project users simply lack the formal training to apply the tool correctly.
One reason for the confusion might be Microsoft Project’s insistence on displaying the day you open the file as the Status Date. Granted, until progress is applied to the schedule nothing happens to the planned dates, but making the Status Date appear to be fluid is not a good idea. And I suspect many Microsoft Project users are not changing the Status Date because they think the date has already changed; it has, but until the schedule is calculated this date is meaningless. This is why the true Status Date is often the project start date.
If everything went according to plan, we could get away with not moving the Status Date. But that has not been my experience for the past 29 years that I have worked as a scheduler in the construction industry. Field Marshall Helmuth von Moltke famously said, “no plan survives contact with the enemy.” Battles and projects are both unique endeavors where anything can happen. Work often does not start according to the planned dates, takes longer to complete, or is performed out-of-sequence. Moving the Data Date is the only thing that keeps the schedule honest.
When I started my career as a professional scheduler I would often sit down with my clients and mark up the large (30″ x 42″) hand-drawn logic diagrams and tell them, “here are the activities on the critical path; it has been four weeks since I was last here, so you need to give me four weeks’ worth of progress along this path.” My clients would sometimes think I was being a bit harsh, but I knew what would happen when I changed the Data Date. The work not performed gets shoved to the right.
Temporary procrastination does not always cause an immediate impact to project completion, however. Activities that are ready to start but not currently on the critical path may still have enough Total Float to wait until the next schedule update. My favorite way to track these lagging, non-critical tasks is the Schedule Performance Index (SPI). The SPI compares planned progress in the baseline schedule to the actual progress in the current schedule, expressed as follows:
SPI = Performance Percent Complete ÷ Schedule Percent Complete
Performance Percent Complete sounds mysterious, but normally it is the same as Activity Percent Complete. You can check this setting under Admin > Admin Preferences > Earned Value. Schedule Percent Complete is merely the progress expected per the Project Baseline, whatever that might be. It is important to check which schedule is assigned as the Project Baseline since it may have been changed recently.
Because Performance Percent Complete is the numerator in the above equation an SPI of 1.00 or greater means that more work has been performed than expected. This is also quite hard to achieve, since SPI is based on the early dates in the schedule. So not starting a non-critical activity as early as possible hurts SPI just as much as starting a critical path activity late. For this reason I usually run SPIs filtered by: (1) all activities, (2) critical path, and (3) non-critical activities for comparison.
An SPI of 0.80 would tell us that we failed to complete 20% of the work scheduled for the current update period. Early in a project the SPI may not look so great, but the closer we get to the end of the project the SPI has to improve if we have any chance of finishing on schedule. The baseline can be the previous update and still be valid in some situations. We may have deviated so much from the original plan that running the SPI off the original plan is simply not relevant.
I do warn my students there is no clear threshold for SPI where being under a certain number means the project is clearly behind schedule. The most important thing is the trend. We cannot keep ignoring work that is otherwise ready to start if we want to avoid mass chaos during the waning moments of the project. Unless it will somehow cost us more money to start activities on time, what excuse have we got?
The only drawback to SPI is that the schedule must be resource-loaded, either costs or units. Without knowing the “weight” of each task Primavera cannot compare the progress of one task to another. The activity durations might be the same but the daily effort to perform the tasks can be quite different. In any case, we must still consider that not every activity may be resource-loaded (such as submittals) so SPI will not tell us anything about the progress on these tasks.
Getting back to the snowplow, the analogy that I always use is a broom sweeping the remaining work to the right. (Why we tend to see the future as being to the right and the past as being to the left is a bit curious, as if time travels west to east, but we seem to accept this as making sense). One of the participants in my Kansas City class mentioned how they think of the Data Date as a snowplow. I liked their analogy so much I warned them I would use it in my blog. And so I did!