Defining an Update Methodology (Part V)

This post wraps up the discussion on developing update methodologies.  The first three posts addressed some of the basic principles of updating schedules as well as some of the specific mechanical elements within the Microsoft Project desktop client.

The last post reviewed how those principles and mechanisms could be applied to an IT scenario.  In this post, I’ll talk about how construction projects may get updated.  The goal is hopefully to provide suggestions that may be applicable to your own environment.

Again, there will always be nuances, but the general process will likely be as follows:

  1. Set the status date.
  2. Add the Actual Start or Actual Finish
  3. Set the Remaining Duration for in progress tasks.
  4. Progress all completed tasks to the status date.
  5. Reschedule unstarted tasks to the status date (or estimated start date)

Let’s walk through that scenario in a simple schedule.


In the simplest case, we first update the Actual Start or Actual Finish for the tasks that have actually started or finished.  I update the following:

  • Actual Finish for the Project Started milestone.
  • Actual Start for Task 1.
  • Actual Start for Task 4.


Then I set the Remaining Duration field for each of the tasks.  Generally, I would enter a Remaining Duration that pushes the new Finish date out to the estimated finish date that my resources are reporting to me.


If I am using Project Server, I might add a custom field for Estimated Finish to the My Tasks sheet, then roll the Estimated Finish field into the Remaining Duration field using a macro as part of the update process.

Then I select the option to Update the Project from the Project tab.  In this case, I select the started tasks first and set the options to progress the tasks as follows:


I could also use the Mark as Scheduled option in the Task tab to accomplish the same thing.


Note how % Complete automatically updates…


From there, it’s a simple step to reschedule any unstarted tasks to after the status date – again using the Update Project button.

Facilitating the Process

One method to facilitate this process is to add a custom field and grouping that would group tasks by whether or not they are in progress or unstarted.  A formula to establish that in a spare text field might look as follows:

IIf([% Complete]<100,IIf([Actual Start]<>ProjDateValue(‘NA’),”In Progress”,IIf([Start]<[Date1],”Unstarted”,””)),””)

…where Date1 is configured to equal the Status Date.


Group by it, and you would get the following view.


Review the process above, and the view makes things simpler.  If I apply the view after I’ve entered all of the Actual Start and Finish dates, then I can simply select the In Progress tasks to progress to the status date and the Unstarted tasks to reschedule after the status date.

Better yet, as discussed above, I could develop some form of VBA automation to refer to that field and update my project with a single key stroke.

Comparing Construction and IT

So now we’ve looked at two different scenarios, what is the fundamental difference? In both examples, we follow the two commandments of schedule updates, i.e. no incomplete work before the status date and no completed work after the status date.

However, we make different assumptions about why the task took longer than expected, i.e. whether the estimate was incorrect or whether the team was pulled off of the task.  In the example above, we assume that the team has been working continuously since the Actual Start date for the task.  In IT, we assume that the work was interrupted.  Are either examples always true in any industry?  No, what we’re attempting to do is to define a process that captures the bulk of the project updates, but there will always be tasks that don’t match this particular model.

Once we remove that assumption that the work was interrupted, % Complete becomes essentially useless for data input.  In that case, once the resource identifies the Actual Start and the Remaining Duration, the scheduler calculates % Complete for the resource.

Defining an Update Methodology (Part V)

Defining an Update Methodology (Part IV)

Continuing in an ongoing discussion on defining an update methodology….in this episode, I’d like to talk about a couple of scenarios specific to IT.  Tomorrow, I’ll talk about construction.  The general concept is to introduce two diametrically opposite update methodologies to hopefully identify patterns that may be useful to your onw specific circumstances.

IT Scenarios

Typically, I see IT update scenarios come in two, or maybe three flavors:

  1. Percent Complete
  2. Timephased Actuals (no Project Server)
  3. Timephased Actuals (with Project Server)

Regardless of the specifics, the general process invariably is as follows:

  1. Set the status date.
  2. Import/Enter/Add the Actual Work or % Complete.
  3. Reschedule incomplete work after the status date.

…although with time entered via Project Server, I might flip items #1 and #2.

So let’s take the simplest example for illustration purposes.  In this case, we have a couple of tasks that should be in progress or completed.  The status date has been set for a week after project start.


I then update several of the tasks:

  • Project Started is 100% complete.
  • Task 1 is 25% complete.
  • Task 4 is 100% complete.
  • Task 5 is 50% complete.


As we can see, since I had the Project settings configured properly, the entire schedule updates automatically.  In all, I entered exactly 4 points of data.

Let’s fast forward another week.  The status date has been pushed out another week.  Let’s say at this point that Task 1 was completed, but Task 5 made no progress as the team was pulled off the project temporarily to perform break-fix work.  Similarly, Task 2 hasn’t been started.

I update Task 1.


I then use the Update Project button on the Project ribbon to reschedule incomplete tasks.


…which yields the following result…


…and means my schedule no longer violates the two commandments of project updates, i.e. there is no incomplete work prior to the status date, and there is no completed work after the status date.

Note however that the tasks appear to have been interrupted – which in fact was the case as the teams were pulled off the tasks and put on other work.

Adding Complexity

Now, how do we add complexity to this model?  Let’s say that we want to track Actual Start as well as % Complete.  In this case, we add the Actual Start field to the project, enter that data, then pretty much continue as discussed above with % Complete.


Easy enough.  Now how about Remaining Duration?  In this case, I might implement the following process:

  1. Set the status date.
  2. Import/Enter/Add the Actual Work or % Complete.
  3. Reschedule incomplete work after the status date.
  4. Update Remaining Duration.

Dealing with Interruptions

To focus on a specific scenario, what about if the team was pulled off of a task, and you’re not sure when they will be able to return to the task?  If we follow the process above, the task will resume again right after the status date.  That may or may not be the case.  Perhaps we might assume that Task 5 will resume a week later.

In that case, we would add the Resume field to the project, and update that to control when we believe the team will return to the scheduled task.


…and that’s essentially an oversimplified view of updating projects in an IT setting.  If you actually imported timesheets from Project Server (or manually entered them in the Resource Usage View), you wouldn’t really change up the process all that much.  In that case, simply import the data, reschedule incomplete work after the status date, then review the Remaining Duration and Resume fields to ensure that the project data appears correct.

Now, of course there are nuances and complexities that will be specific to your own scenario, but hopefully that captured the essential basics of updating an IT project.

Tomorrow, let’s look at the same principles applied to construction projects.

Defining an Update Methodology (Part IV)

Defining an Update Methodology (Part III)

This is the third post in a short series on determining an appropriate enterprise-wide project update methodology….or actually, just determining an appropriate project update methodology – as what I am writing about could be implemented on a single project just as well as across a large number of projects.

In the previous posts, I talked about reviewing some of the organizational factors that might influence how the update process is structured.  I then went into the Microsoft Project client to review some of the settings that control how updates are applied.

In this post, I’d like to continue looking at the mechanics that govern how updates get entered in the system.

On Setting the Status Date…

First off, the status date is a critical bit of the update methodology.  I am constantly amazed by end users who attempt to update their schedules without using the status date.  Personally, I don’t really understand how such a thing is possible.

Put simply, the status date is the last date upon which the the data input into the schedule model was complete.  If we update the schedule every Friday, and today is Wednesday, then the last status date would be the previous Friday.

The issue with the status date is that when it is used in a Project schedule that doesn’t display the time, simply entering a date will default the status date to 8AM of that date.  So if I enter Friday as 12/16/2011, then the system will assign a default of 12/16/2011 8:00AM, which in a traditional corporate calendar translates essentially into 12/15/2011 5:00 PM.  Depending on the specific update methodology, this may get confusing.

Take the following example….in a construction scenario, I am importing Actual Costs from an external application and applying them to the project, having them accrue as of the status date.  If I update my schedules monthly at the end of the month, and I set my status date for 12/31/2011, then the system will accrue all costs as of 12/30/2011 and not as of 12/31/2011.  In theory, no status will appear on that day.

For this reason, I’d recommend as best practice either specifying the status date as 5:00 PM on a specific date or simply set the status date for the day after the “real” status date.  In an IT project, where I update the schedule each Friday, I would simply set the status date to the Saturday following to make updates easier.  In a construction project where I update at month end, I would set the status date to the first of the month following.

Lastly, here’s a trick to get the status date to appear in your schedule…and a filter to show in progress tasks…

Identifying Tasks to Update

So now we’ve identified how to enter the status date properly, the next issue lies in identifying which tasks need to be updated.  In theory, depending on your schedule granularity, you probably will never have to update more than a couple of tasks each update cycle.  If you set up your schedule properly, with the appropriate dependencies, updating the in progress tasks each cycle will result in an up to date schedule model.

My recommendation is to simply develop a filter or a view that will identify any task that requires updating.  This process has been made a bit more complicated with the introduction of manual scheduling in Project 2010 which necessitated the conversion of the default Start field to a Text field.  In 2010, the way around this is to develop a filter on the Scheduled Start field.  (Click here for more on that…)

This is also complicated by the fact that the Status Date is not available as a task level field.  Hence, the first step is to make the status date available for use in a filter.  To  do this, we use a custom Date field, and set it equal to the Status Date.


Then we create a filter that looks something like this:


…and I think that’s that.  Now we have the stage set, let’s get back to some process discussion with my next post on the topic….

Defining an Update Methodology (Part III)

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)

Defining an Update Methodology (Part I)

Every organization has a different level of scheduling maturity, and it’s rare that this scheduling maturity is homogenous across the entire group of schedulers.  Some are invariably more advanced than others, which necessitates almost a sliding scale of process definition – a rigid, detailed definition for the more advanced schedulers, and a less defined process for the schedulers still learning the “dark arts” of project scheduling.

..or perhaps I have that flipped.  Maybe the more rigid processes should be for the less mature schedulers, and the less rigid process should be for the experienced ones.

Regardless of which side on that debate you take, I would say that inevitably in any exercise in EPM maturity bootstrapping, there will be a discussion about what the planned organizational update methodology will be.  That may be a broad discussion with the entire organization as an effort to define a standard or that may be a limited discussion with a specific group of schedulers who have proclaimed themselves ready for it after scheduling for some time.

Like many events in the EPM deployment lifecycle, it can be difficult to gauge when schedulers are ready for this discussion.  Try it too soon and you turn them off the engagement due to overly rigid processes.  Try it too late, and you end up with multiple, very specific views on how to update projects that need to be reconciled into a single consensus.  I personally prefer to wait until a couple people start asking me very specific questions around updating schedules.

…and sometimes, just sometimes, the update methodology is logically derived from stated organizational reporting requirements.  That always simplifies things.

So I figured I’d waste a couple of electrons and go ahead and post a recap of various update methodologies to give a range of options.  In this post and the next couple of posts, I’d like to address how to define an update methodology, and then throw out some examples from diametrically opposite fields, specifically IT and construction.  Hopefully, those examples may give you something to think about as you design your own update methodology.

For today’s post, I’ll focus on the basic principles of updating projects….

Focus On the Why and Then the How

The first question I always ask a scheduler when attempting to suss out an appropriate update methodology would be “What information do you really care about?”

Let’s face it, Microsoft Project, and any other desktop scheduling tool allows users to input a whole slew of data to update a project: Actual Start, Actual Finish, % Complete, Physical % Complete, % Work Complete, Actual Work, Actual Duration….not to mention timephased actual data imported from timesheets or LOB applications.

At the end of the day though, I would submit that there’s really only one point of data that is absolutely required at each status update cycle: “Are you done yet?”  That keeps things simple and binary.  Picture it, at your next status meeting, just ask every resource that one question about any ongoing tasks.

Of course, that question only works when your tasks are defined granularly enough.  Specifically, my recommendation is generally to cap your task durations at a maximum of one reporting period, whether that be a week or a month. When tasks begin to exceed a single reporting period, that one question of “Are you done yet?” begins to lose effectiveness.

But think of it, and not to quote fellow MVP Eric Uyttewaal too much, but there was a great section in his Forecast Scheduling book which talked about how project managers only care about the future.  Accountants care about the past.  Do I really care about all of the historical data in a project schedule?  Nine times out of ten, I would say, no, I don’t care about the actual duration.  All I want to know is if it’s done or not.  That gives me enough data to replan my remaining schedule.

That simplicity begins to break down when we start throwing effort and cost into the equation.  Once I begin tracking that, I do need to start collecting a whole lot more data points – although again, the data collected needs to be mapped to my specific needs.  Do I need to know when the work was performed?  Not really.  All I care about is how much of my budget has been consumed, so that I can define how much of my budget is left, and how much work there is remaining that needs to get performed within the constraints of that budget.

So even in a resource consumption scheduling model, I often don’t need a complex update system.  I just need whatever will tell me what’s left in the resource bucket, how much work is left, and how much time I have left to get that work done.

Let’s throw another layer of complexity onto our analysis.  What about if we’re performing these projects under the guidance of a PMO charged with “continual process improvement” or as I wrote a couple of weeks ago, managing outcome improvement?  Then again, we need to start tracking more data, as continual process improvement usually comes hand in hand with metrics on performance, and identification of methods of improving (i.e. shortening) the duration of similar tasks on similar projects.

So that’s the ‘why’…

…But Let’s Be Realistic…

The second question you should ask yourself when planning an update methodology is really “how much authority does the PM have to request/demand data from the resources?”

If you’re a lowly PM working in a research organization where you’re trying to collect task status from highly educated Ph.D’s, good luck collecting historical data, timephased actuals, or any of the other points of data that a PMO might desire.  Unless that practice is deeply embedded in the organizational culture, you’ll have a tough time getting the time of day from your resources.

Similarly, unless you have the organizational might backing you up, if you’re a construction scheduler working to support a construction PM, it may be tough for you to penetrate the complex network and relationships of contractors that are actually doing the work on your project – although there you’re assisted by the fact that you can always define your data requirements as contractual obligations.

Hence, you want to balance out how much data the organization is requiring with how much data you can actually get from your resources.  Ensure that you factor in the difference between the level of both your formal and your actual authority.

Oh Yeah, One More Thing

In writing this series of blog posts, I also realized that there’s probably one other key bit of environmental background that we need to consider when planning an update methodology.  Are the resources dedicated or not?  If the task is behind schedule, can we make the default assumption that it’s behind schedule because the resource was pulled into another endeavor (IT) or because the resources doing the work encountered a variable that slowed progress (Construction).  There’s never going to be a firm rule that applies to 100% of the cases, but you can generally identify a default behavior.

Next up…we continue to look at the basic concepts of updating a schedule and how those are configured in Microsoft Project.

Defining an Update Methodology (Part I)

Scheduling Milestones for Specific Days of the Week

Here’s a little trick that may come in useful when developing your schedules.  The scenario here is that you have a milestone such as key meeting or review or training kick off or go-live date, but that event has to happen on a specific day of the week.

Let’s take a typical consulting example.  Let’s assume that the consultant is traveling to the client site, and generally works Monday through Thursday on-site.  The hypothetical consultant returns home and works remotely on Friday.

Now let’s say that the consultant wishes to schedule a key internal review of the project work.  He doesn’t want to use precious on-site time to have that conversation, instead choosing to schedule that discussion on a Friday. 

We can first set up that discussion as a milestone.


Create a new calendar that we will call “Off Site.”  Set every day but Friday to be non-working time.


Apply the calendar to the milestone. Set the option Ignore Resource Calendar to “Yes” if you have a resource assigned.  That’s not required in this case, but it could be if the resource wasn’t scheduled to work on Friday, or as more often happens, the task falls on a weekend.


Note that the milestone seems to ignore the calendar.  This is because the milestone, having no duration, is not subject to the task calendar.

Now, set the milestone to a duration of 1 minute.  The task moves to a Friday.


Check the option to Mark the Task as Milestone.


You now have a milestone that is only going to happen on a Friday.


Have a whole string of tasks that have to start on a specific day of the week?  Just lead off with one of those 1 minute milestones, then add a bunch of successors.

Scheduling Milestones for Specific Days of the Week

Task Type Use Cases in an IT Environment

In training sessions, my students traditionally have a tough time grasping the concept of task types and how they may be applied in the real world.   I often get the question of “Which task type would you recommend for ‘XYZ’?”  To which the response is almost always, “It depends.”  In this post, I figured I’d spend a little time talking about my own personal practices, and see if that sheds some light on task type usage patterns.

Task Types

First off, what are the available task types?

  • Fixed Duration
  • Fixed Work
  • Fixed Units

These task types play the part of variables in the Duration X Units = Work equation that Microsoft Project uses as the basis for a fair number of scheduling calculations.  (Note that the Duration X Units = Work equation should probably be more accurately depicted as Duration X Units (X Person Hours Per Day) = Work.)

The general way to identify which task type you would like to use is to ask yourself the question, “Which of those three variables, Duration, Units, or Work, do I know at this point?  Which variable will not change?”  That is the variable that should be fixed.

Planning the Project

Great in theory, but how does that work in practice?  Let’s take an IT project as an example.  As a consultant, I am often called upon to decompose the project scope and to identify the tasks required to complete the scope.  Since work frequently on similar projects, i.e. Project Server deployments, I might start with a schedule template that already lists the tasks and dependencies.

So my first goal is to work through that schedule list and attach work estimates.  At this point, I am not attaching duration or calculating a real schedule.  All I am doing is working through the list, and adding an estimate of work to each task….80 hours here, 20 hours there, 4 hours there.  Now here’s the trick.  Unless I uncover something new during the planning/estimating process, those hours will not change.  They probably will change when I get into the actual execution of the project, but we haven’t gotten there yet.  Hence, I will set those tasks to Fixed Work.  I don’t want those estimates to change.

Once I’ve gone through a first cut of the schedule and attached hours to the tasks – and set the tasks to Fixed Work, then I’ll go through and play with either the units of allocation of a resource or more likely the duration of a task.  I run through the project and start assessing duration for each of the activities.  Since work is fixed, and I am editing duration, the units field will recalculate – which is what I want.  My duration estimates are usually based on client availability estimates, i.e. I will assume that requirements gathering may take longer or shorter depending on the number of people involved in defining requirements or the complexity of the project.

Again though, unless I uncover something new during this process, the work estimates do not change.

Tracking the Project

Once I’ve reviewed my estimates, added calendars and constraints, then smoothed the overallocations, I tend to flip all of my tasks from Fixed Work to Fixed Units.  “Why?” you ask.  Well, when you get into execution, that’s when I am pretty sure that my work estimates will change routinely.  Similarly, I am pretty sure that my units will stay pretty stable – or at least they will do so for future estimates.  Past estimates will be overridden by the actual hours entered in the system.

So every week, I fill in my timesheet, and my actual hours get transferred back to my plan.  If I book more hours than I expected, units are fixed, and the duration comes in.  If as happens more often, I book less hours than expected, units are still fixed, and the duration gets pushed out.  If, based on partial completion, I change my work estimate, again units are fixed, and the duration is recalculated.

Hence, generally, in an IT environment that tracks hours, I would recommend using Fixed Units task.

So there you have it…..a long winded explanation of why “It depends” is a valid answer.  My recommendation for this specific scenario would be Fixed Work during the estimating and Fixed Units during the execution of the project.

Task Type Use Cases in an IT Environment