Defining an Update Methodology (Part II)

In that last post, I talked about some of the basic considerations in defining a schedule update methodology, and in ascertaining whether or not a process is fit for purpose.  In this post, I’d like to continue that discussion and then get a bit more tactical to look at how Microsoft Project may be configured to support your requirements.

First off, let’s look at the two commandments of scheduling….

The Two Commandments of Updating Schedules

…and I should mention that these are probably heavily inspired by some of the content found on fellow MVP Jim Aksel’s blog here.  There’s a lot of great content over there worth checking out.

After updating your schedule, you should always review it to confirm that the following commandments have been met:

  1. Thou shalt have no incomplete work prior to the status date.
  2. Thou shalt have no completed work after the status date.


Now the actual implementation of these two commandments may vary by organization, but as long as these conditions are met your schedule is probably pretty good – or at least better than the other PMs in your organization, which is really the quality standard we should all strive for.

Flipping the Right Switches

There’re a lot of checkboxes and radio boxes that control how data gets into the Project schedule, but I’ve almost always focused on the same basic ones.  The primary settings reside in the File > Options > Advanced tab.


Here, I would almost always recommend toggling the settings the way they’re displayed above.  I can’t recall if that is the default, but it really should be.  These settings affect tasks updated using the % Complete method.  For instance, if you configure your project as shown above, entering 25% on a behind schedule task will automatically push the remainder of the work after the status date…


Similarly, all completed work will be shoved to the left of the status date which makes logical sense.  You can’t exactly do work in the future can you?  Similarly, you can’t go into the past and do your work on schedule given that we’ve already missed that opportunity.

The secondary options in the above illustration, i.e. the options to move the start of remaining work and the end of completed parts forward to the status date are determined by how your organization wants to track work. 

For instance, the first unchecked option, “And move start of remaining parts back to status date” is basically governed by how optimistic your organization is.  If you’re an optimistic sort, you can check that.  Then, if any task progresses ahead of schedule, the finish date will move to the left.  In the real world, I rarely see this, as what typically happens if we’re ahead of schedule is that the team slows down….and even if the task finishes ahead of schedule, the successor team is probably not ready to start ahead of schedule….assuming of course that we don’t have dedicated resources.  If you do have dedicated resources, you might make different sets of assumptions around how you would like the update cycle to work.

Note that, as  I learned recently, all of those settings are negated if the Updating Task Status Updates Resource Status checkbox is unchecked.  I am not sure why the functional dependency is there, but if that box is unchecked, the schedule will not apply the options above.


I almost always define a default setting for these options and incorporate that into the installation package – something which can be done either with these instructions from Paul Mather, ensuring each template is configured with these settings, or if a macro is used to facilitate the update cycle, adding those settings to the macro to ensure they’re all set the way we need them to be.

Lastly, for good measure, the status date is correctly set in either of the two locations identified below.


The status date may also be set on the ribbon, but note in 2010, that this setting is a bit misleading.  There’s an issue where if the status date hasn’t been set, it appears to display today’s date.  That’s not really the case though, as in the above illustration, the status date is blank.

Next up…let’s talk more about setting the status date and on a couple other mechanical details before we get into specific scenarios.

Defining an Update Methodology (Part II)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s