In this tutorial, we will learn what it means to status a project schedule. If you are scratching your head asking, what the heck is statusing the schedule, then this tutorial is for you! I am going to explain what statusing the schedule is, why we need to do it, and walk through the statusing process. And don’t be alarmed… A lot of project managers and others in the project management industry don’t understand what statusing a schedule is. So, you are not alone!

What is Statusing the Schedule

What is statusing the schedule? Statusing the schedule is the process that we will use to record actual progress in the schedule as the project is executed. When we started the project, all of our tasks and milestones had forecast dates. If everything is executed as planned, then all tasks and milestones would be executed on their original forecast dates and the project would finish exactly on the day it was forecasted to be finished.

But is that realistic?? We wish that it was! Who doesn’t want their project to be executed exactly as planned! The reality is that this seldom happens, if ever. Some tasks might start late or finish late. Or they might take longer than planned. Some tasks might even start early or finish early, or take less time than planned.

The point is, things change. And these changes happen for a variety of reasons. Regardless of the reason, because things change, our project schedule must be updated with actual progress periodically so that these changes can be reflected in the forecasts that our schedule is producing. So if the schedule is statused properly, it will continue to produce reliable forecasts.

The Status Date

As we record progress, we are going to use a specific date as the point of reference. This date is called the Status Date. You may also hear it referred to as the Data Date. This date is in the past. It could be yesterday afternoon. It could be last week. It could be every Friday afternoon. It doesn’t matter what date you use, but it does need to be in the past. The reason for this is simple. If we are asking our team to come prepared to provide updates up to the Status Date, then the Status Date has to be in the past and already occurred. If the Status Date was in the future, our team would not be able to give us actual updates through the Status Date.

I prefer to set the Status Date to Friday afternoons on smaller projects that are using weekly updates. And on larger projects that are doing monthly updates, I may set the Status Date for the last day of the month. Once we choose the Status Date, we will then set the Status Date in our Microsoft Project schedule under the Project tab, as shown below. I also added an orange grid line in the Gantt area to represent the Status Date. The Status Date has been set for Friday afternoon 1/5/2018.

Once we set the Status Date, we will then tell our team to be prepared to provide task updates up to the Status Date. For our above project schedule, I may be doing a meeting on Monday morning on 1/8/2018. I will let the team know to come to the meeting on Monday morning with task updates through 1/5/2018.

By using the Status Date instead of our current date, we set a common reference point for everyone. As such, if someone opens the schedule, they simply have to refer to the Status Date to determine when the schedule is updated to. We don’t have to guess. This is very useful information since the day you receive a schedule may not be the day that the schedule was updated.

Microsoft Project Fields that support Statusing

There are several fields that we will refer to in our discussion on statusing. These include:

  • Start
  • Finish
  • Actual Start
  • Actual Finish
  • Remaining Duration
  • Physical % Complete

These fields have been added to our project schedule as shown below. We will learn more about how these fields will be used later.

Basic Rules of Statusing the Schedule

There are a few basic rules that we have to observe as we status the schedule. The rules focus on the status date. We need to consider the status date as the current date in our schedule.

Rule 1: The Past has Already Occurred

Anything earlier than the Status Date is considered in the past. If the Start or Finish date is earlier than the Status Date, then it must have occurred since it is in the past. Therefore, it must have an Actual Start or Actual Finish date assigned to it. If the Start or Finish did not occur, then the date needs to be rescheduled into the future. If we look again at our sample schedule, we see that Task 1 has a Start date of 1/1/2018. And we have a Status Date of 1/5/2018. 1/1/2018 is before the Status Date. It is in the past. If the task did not start, it must be rescheduled to have a Start date later than 1/5/2018.

Rule 2: The Future has not Occurred

Anything later than the Status Date is considered in the future. If a Start or Finish date is in the future, it could not have occurred yet. The future hasn’t happened so there can be no Actual Start or Actual Finish in the future. If we again look at our sample schedule below, we see that Task 1 has a Finish date of 1/12/2018. And we still have a Status Date of 1/5/2018. Therefore, we should not have any Actual Finish date assigned to the task. It could not have finished on 1/12/2018. Task 1 could have finished on 1/5/2018 or earlier. If it did, we would record the appropriate Actual Finish date.

The Statusing Process

During the statusing process, we will be focused on getting some information from our team. We will want to know the Actual Start date if the task started. We will want to know the Actual Finish date if the task finished. If the task is still in progress, we will want to know how many more days it will take to complete the task. And finally, we may even want to know the physical percent complete value of the product or deliverable that we are developing.

Through this process, we will be using a new button on our Task ribbon that you may not have used before. It is called Mark on Track. Get familiar with where it is since we will be using throughout the statusing process. The Mark on Track button is what tells Microsoft Project to record duration used up to the Status Date.

We will want to have a set of standard questions to ask our team to get this information. We will ask these questions for any incomplete task that has a Start Date that is equal to or before the Status Date.

Question 1

If the task started, when did it actually start? Input this date into the Actual Start field and click Mark on Track. If the task did not start, go to Question 2. In our sample schedule, let’s assume that Task 1 started on 1/2/2018. We input that date into the Actual Start field and click Mark on Track.

Once we do this, we see three things changed in our schedule. We now have an Actual Start date of 1/2/2018. We also see that the Remaining Duration adjusted from 10 days to 6 days. This is because the task started on 1/2/2018 and progress was recorded through 1/5/2018 which used 4 project days of duration out of the original 10 days planned. And finally, we see a progress a bar represented by a dark blue bar added in the Gantt chart that extends from the task start to the Status Date. We are now ready to move to Question 2.

Question 2

If the task was scheduled to start but did not start, what is the new forecasted Start date? Input this date into the Start field to reschedule the task into the future. If we were using the schedule from Question 1, we would skip Question 2 since the task did actually start. But let’s assume that the task did not start. The task owner comes to the meeting and says that the task is now forecasted to start on 1/9/2018. We input that date into the Start field to reschedule the task into the future as shown below.

Once we do this, we see a few things that changed in our schedule. First, we see that the Start date is now set to 1/9/2018 which also pushed our task in the Gantt chart area past the Status Date, into the future. We also notice in the Indicator field that a Date Constraint has been applied to the task. This is normal. Whenever we reschedule a task into the future by choosing a new Start date, a Date Constraint will be applied. And now we are ready for Question 3.

Question 3

If the task finished, when did it actually finish? Input this date into the Actual Field field. Let’s assume that our task did start on 1/2/2018 as we saw after Question 1.

If the task owner comes back and says that the task finished on 1/5/2018, we would input that date into the Actual Finish date as shown below.

We then see an Actual Finish date of 1/5/2018. We all see that the duration of the task was changed to 4 days since the task started on 1/2/2018 and finished on 1/5/2018. And finally we notice that the Gantt bar has been shortened to end on 1/5/2018 and it has been completely filled in with the dark blue progress bar. We are now ready to move onto Question 4.

Question 4

If the task did not finish and is still in progress, how many more project days are required to finish the task? Input this value into the Remaining Duration field and click Mark on Track. Once again, let’s refer back to our schedule from Question 1 which had the task start on 1/2/2018.

If our  task started on 1/2/2018 but did not finish yet, we now need to validate the Remaining Duration with the task owner. It currently says 6 days. If this value is accurate, we can skip this question and move onto Question 5. If the task owner says more or fewer days are required, then we can adjust the Remaining Duration value and then click Mark on Track. Let’s assume the task owner says that they will be able to complete the task in 10 days rather than 6 days. We input 10 days into the Remaining Duration field and click Mark on Track as shown below.

Once the Remaining Duration value is set to 10 days, we will now see that the Finish date has extended from 1/15/2018 to 1/19/2018 and the total task duration has increased to 14 days rather than the original 10 days. Once item to note before we move to Question 5. If the Remaining Duration value changes after clicking Mark on Track, continue changing the Remaining Duration value to the desired value and clicking Mark on Track until it does not change anymore. You may need to do this several times depending on how significant the change was from the original forecasts.

Question 5

This question is optional. What is the physical percent completion estimate for the task? We will then input this value into the Physical % Complete field. Let’s assume that our task once again started on 1/2/2018, it did not finish, and the Remaining Duration is 10 days. I can now ask, what physical percent complete is the deliverable that this task is producing and then enter this value into the Physical % Complete field as shown below. In this example we will assume that the task owner said the task is 40% complete. It is important to note that we are talking about the physical percent complete of the deliverable. You must make this point clear to the task owner when asking him or her for an estimate of physical percent complete.

So why is Step 5 optional? Well quite frankly, getting accurate physical percent complete values can be very difficult. People tend to be overly optimistic and inflate the physical percent complete values. They don’t intend to be inaccurate. It isn’t malicious. It’s just the way that it is. Because of this, I recommend not even asking for a physical percent complete unless you have some method of validating the physical percent complete value. It is much more reliable to ask team members for an estimate of how many more project days they need to finish the task as we are doing in Step 4. So don’t worry about physical percent complete. Worry about how many more project days are needed. This will ultimately produce more accurate forecasts.


That completes this introductory tutorial into the statusing process. If we follow the process outlined in this tutorial, we will have a schedule that is up to date through the Status Date. And, if our schedule was built correctly, the schedule will continue to produce updated, reliable forecast dates as we execute the project and dates change from the original plan.